[Bug] File permissions across domains

[Corinna Vinschen]

On Apr 12 21:16, Achim Gratz wrote:
> Corinna Vinschen writes:
> > I inspected the source code which handles this kind of thing.  What it
> > does is to ask Windows for permissions of SID X on file Y, using AuthZ.
> 
> That seems to be working correctly.  For all old domain SID I've looked
> at, they've been prefixed by 0x7FFF0000 when seen by the new domain
> machine, so both the SID and conversion of uid/gid works correctly.  If
> it didn't I'd not be able to see my homedir and other stuff too.

That's not what I was talking about.  Of course the SIDs are correct,
but that has nothing to do with file permission evaluation.  AuthZ
is only doing the latter.

> > See sec_acl.cc, line 1127ff.  This calls a function
> > authz_get_user_attribute which in turn calls a method
> > authz_ctx::get_user_attribute, sec_helper.cc, line 811ff.
> >
> > This method checks if the owner of the file is the current user.  Given
> > this test is done using SIDs, not Cygwin uids, this should be you, *iff*
> > you're logged in as the same user on both machines at the time you
> > created the above output.  This in turn should create the Authz context
> > for the current user from the current process token and the subsequent
> > AuthzAccessCheck should give the same result on both machines.
> 
> I've looked briefly at the source code, but I don't really see what's
> going on.

It's dirt easy:

1. fetch an AuthZ context for the current user from the current
   process token:

     AuthzInitializeContextFromToken

2. Ask AuthZ for the permissions on file Y:

     AuthzAccessCheck

authz_ctx::get_user_attribute is really only a few lines.

> While poking around, I noticed that the error/bug is far more
> specific than I thought:
> 
> The merging of the access rights bestowed by access groups is working
> correctly if the file is not owned by the current user, but fails if
> it's owned by the current user.  I have a second account that I must use
> for doing anything administrative and it's also in the old domain.

Ok.  However, MSDN explicitely suggests to fetch the AuthZ context
from the current user token, if the idea is to ask for the permissions
of the current user.  It's much less costly than calling
AuthzInitializeContextFromSid.

Is your account an admin account by any chance?  If so, does it work if
you run in an elevated shell?

I'm reluctant to switch to AuthzInitializeContextFromSid all the time
for the reasons outlined above.

> > One reason could be that you're member of OLD+cygwinupload only on the
> > old machine, while this group is not in your current process token when
> > logged in on your NEW machine.  You should check your token.  In terms
> > of group membership an `id' call should suffice.  But there may be
> > other differences in the token.
> 
> That all seems to be correct as far as I can tell.

I don't understand what you're trying to say here.  Are there
differences or not?

> > If that's not the problem, you will have to debug this, because
> > only you have access to this environment.
> 
> Given the sheer size of the function I'd appreciate if you could point
> out on which line the decision is made whether the file is owned by me
> or not.

I pointed pretty much exactly at the lines in question.  The decision is
made in authz_ctx::get_user_attribute, as is the AuthZ call to ask for
the actual permissions, just two AuthZ calls and a mere 50 lines of
code.

Only if the owner SID is not the current user,
authz_ctx::get_user_attribute calls authz_ctx_cache::context, just
a few lines above, and also only about 30 lines of code.

Worst of all, there are comments!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20180413/96466c30/attachment.sig>