This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Bug] File permissions across domains

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.

> See, line 1127ff.  This calls a function
> authz_get_user_attribute which in turn calls a method
> authz_ctx::get_user_attribute,, 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.  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.

> 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.

> 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.  It seems that I should step through from that point on to see
where it makes the (wrong) decision to not merge access rights via

> It wouldn't change anything since the access check is performed on
> SIDs, not uids.


+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]