On Apr 11 19:17, Achim Gratz wrote:
> Corinna Vinschen writes:
> > This is a bit low on detail.  What does icacls say about this file?  How
> > does getfacl report the ACL on a machine in the old domain?  What does
> > ls -l report on the file on both machines?  Does an strace on getfacl
> > report an error in ACL checking?
> 
> There is absolutely no error when stracing getfacl on either machine.
> From the machine in the new domain (my account is in group cygwinupload
> and access on this share is via ACL only, I can't change ACL):
> 
> --8<---------------cut here---------------start------------->8---
> /mnt/upload > ll bla
> ----rwx---+ 1 OLD+gratz OLD+Domain Users 0 Apr 10 15:21 bla
> (1011)/mnt/upload > getfacl bla
> # file: bla
> # owner: OLD+gratz
> # group: OLD+Domain Users
> user::---
> group::---
> group:OLD+FileOperators:rwx
> group:OLD+cygwinupload:rwx
> mask:rwx
> other:---
> 
> (1012)/mnt/upload > `cygpath -S`/icacls bla
> bla OLD\FileOperators:(I)(F)
>     OLD\cygwinupload:(I)(M)
> 
> Successfully processed 1 files; Failed processing 0 files
> --8<---------------cut here---------------end--------------->8---
> 
> The same thing on a machine in the old domain:
> 
> --8<---------------cut here---------------start------------->8---
> (1007)/mnt/upload > ll bla
> -rwxrwx---+ 1 gratz Domain Users 0 Apr 10 15:21 bla
> (1008)/mnt/upload > getfacl bla
> # file: bla
> # owner: gratz
> # group: Domain Users
> user::rwx
> group::---
> group:FileOperators:rwx
> group:cygwinupload:rwx
> mask:rwx
> other:---
> 
> (1009)/mnt/upload > `cygpath -S`/icacls bla
> bla OLD\FileOperators:(I)(F)
>     OLD\cygwinupload:(I)(M)
> 
> Successfully processed 1 files; Failed processing 0 files
> --8<---------------cut here---------------end--------------->8---
> 
> Checking how Cygwin reads my own account results in exactly the same SID
> on both machines as it should, but of course Cygwin translates that to
> different uid / gid values due to the presence of the domain prefix when
> I'm logged into the machine in the new domain:

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.

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.

Bottom line is, I have no idea why this doesn't work in your case.  I
can neither test nor debug this.

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.

If that's not the problem, you will have to debug this, because
only you have access to this environment.

> I have not yet tried to force the account back to a prefix-less
> interpretation via /etc/passwd (I had to do that in my home network
> without a DC to solve a similar problem, but I'd like to avoid that
> here).

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


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat