Re: [Bug] File permissions across domains

Re: [Bug] File permissions across domains

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

Same here, belong on the Cygwin ML.  Redirecting.

Corinna

On Apr 10 18:47, Achim Gratz wrote:
> 
> We're in the midst of switching to a different LDAP domain
> organisation.  All my accounts still arein the old domain and that leads
> to problems when lookking at shares from a mchine in the new domain:
> 
> --8<---------------cut here---------------start------------->8---
> (1027)/mnt/upload > touch bla
> (1027)/mnt/upload > getfacl bla
> # file: bla
> # owner: OLD+gratz
> # group: OLD+Domain Users
> user::---
> group::---
> group:OLD+cygwinupload:rwx
> mask:rwx
> other:---
> 
> (1028)/mnt/upload > ls -l bla
> ----rwx---+ 1 OLD+gratz OLD+Domain Users 0 Apr 10 14:41 bla
> --8<---------------cut here---------------end--------------->8---
> 
> So Cygwin correctly figures that I'm the owner of the file, but fails to
> translate my access rights (via group OLD+cygwinupload) into the owner
> part of the modes like it does when I look at the same file from a
> machine in the old domain.  That in turn confuse sprograms that check
> the modes before the ACL (like Git) to tell me that I can't access the
> files (or that there is no repository in the case of Git).
> 
> 
> Regards,
> Achim.
> -- 
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
> 
> SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Bug] File permissions across domains

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

On Apr 11 09:03, Corinna Vinschen wrote:
> Same here, belong on the Cygwin ML.  Redirecting.
> 
> Corinna
> 
> On Apr 10 18:47, Achim Gratz wrote:
> > 
> > We're in the midst of switching to a different LDAP domain
> > organisation.  All my accounts still arein the old domain and that leads
> > to problems when lookking at shares from a mchine in the new domain:
> > 
> > --8<---------------cut here---------------start------------->8---
> > (1027)/mnt/upload > touch bla
> > (1027)/mnt/upload > getfacl bla
> > # file: bla
> > # owner: OLD+gratz
> > # group: OLD+Domain Users
> > user::---
> > group::---
> > group:OLD+cygwinupload:rwx
> > mask:rwx
> > other:---
> > 
> > (1028)/mnt/upload > ls -l bla
> > ----rwx---+ 1 OLD+gratz OLD+Domain Users 0 Apr 10 14:41 bla
> > --8<---------------cut here---------------end--------------->8---
> > 
> > So Cygwin correctly figures that I'm the owner of the file, but fails to
> > translate my access rights (via group OLD+cygwinupload) into the owner
> > part of the modes like it does when I look at the same file from a
> > machine in the old domain.  That in turn confuse sprograms that check
> > the modes before the ACL (like Git) to tell me that I can't access the
> > files (or that there is no repository in the case of Git).

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?


Thanks,
Corinna

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Bug] File permissions across domains

[Achim Gratz]

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:

OLD+gratz:*:2147559089:2147484161:U-OLD\gratz,S-1-5-21-20…441:/home/gratz:/bin/bash
gratz:*:1124017:1049089:U-OLD\gratz,S-1-5-21-20…441:/home/gratz:/bin/bash

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


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Bug] File permissions across domains

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3860 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Bug] File permissions across domains

[Csaba Raduly]

On 4/12/18, Corinna Vinschen wrote:
> 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.

Ouch. Are there so many lines that you have to use hexadecimal notation ?

Csaba
-- 
You can get very substantial performance improvements by not doing the
right thing.
   - Scott Meyers, An Effective C++11/14 Sampler
So if you're looking for a completely portable, 100% standards-conformat way
to get the wrong information: this is what you want. - Scott Meyers
(C++TDaWYK)

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Bug] File permissions across domains

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On Apr 12 09:56, Csaba Raduly wrote:
> On 4/12/18, Corinna Vinschen wrote:
> > 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.
> 
> Ouch. Are there so many lines that you have to use hexadecimal notation ?

Usage analogue https://en.wiktionary.org/wiki/ff.


Corinna

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Bug] File permissions across domains

[Achim Gratz]

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

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

True.


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Bug] File permissions across domains

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3880 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Bug] File permissions across domains

[Achim Gratz]

Corinna Vinschen writes:
> It's dirt easy:

For you... :-)  I know next to nothing about all this stuff.

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

OK.

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

As I said, I have both an admin and a normal account that show the same
behaviour (it makes no difference if the admin account is used with
elevated privileges or not).

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

You're on to something.  I have over 500 groups in my token in the old
domain, but only half of those end up in the token when I'm logged in on
the machine in the new domain (at least as far as Cygwin is concerned as
obviously I can still access the files when I'm actually trying).  I
scheduled an audience with one of the AD guys some time next week, he
thinks he can explain why that happens and hopefully it's something that
can be fixed on the AD side.  Eventually I'll have my account migrated
to the new domain later this year anyway at which point these sort of
problems should go away, but at least for the next two months I'll have
to stick it out.


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Bug] File permissions across domains

[Achim Gratz]

Achim Gratz writes:
>> I don't understand what you're trying to say here.  Are there
>> differences or not?
>
> You're on to something.  I have over 500 groups in my token in the old
> domain, but only half of those end up in the token when I'm logged in on
> the machine in the new domain (at least as far as Cygwin is concerned as
> obviously I can still access the files when I'm actually trying).  I
> scheduled an audience with one of the AD guys some time next week, he
> thinks he can explain why that happens and hopefully it's something that
> can be fixed on the AD side.

Here's what I understood of that: The problem was how the group that was
supposed to give me access was set up in AD a long time ago.  Apparently
when you have an AD forest or a federation you can separately flag if
the groups are visible or valid outside the defining domain and it had
been set up to have restricted validity, while still being visible in
all domains.  Only when both these flags are set will the group actually
be in your AuthZ token ("universal group").  Actual file access still
worked since the access was checked on the file server which was in the
"home" domain.  So, the group got converted to a universal one and the
problem went away after that change had replicated to all DC.


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Bug] File permissions across domains

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

On Apr 22 09:25, Achim Gratz wrote:
> Achim Gratz writes:
> >> I don't understand what you're trying to say here.  Are there
> >> differences or not?
> >
> > You're on to something.  I have over 500 groups in my token in the old
> > domain, but only half of those end up in the token when I'm logged in on
> > the machine in the new domain (at least as far as Cygwin is concerned as
> > obviously I can still access the files when I'm actually trying).  I
> > scheduled an audience with one of the AD guys some time next week, he
> > thinks he can explain why that happens and hopefully it's something that
> > can be fixed on the AD side.
> 
> Here's what I understood of that: The problem was how the group that was
> supposed to give me access was set up in AD a long time ago.  Apparently
> when you have an AD forest or a federation you can separately flag if
> the groups are visible or valid outside the defining domain and it had
> been set up to have restricted validity, while still being visible in
> all domains.  Only when both these flags are set will the group actually
> be in your AuthZ token ("universal group").  Actual file access still
> worked since the access was checked on the file server which was in the
> "home" domain.  So, the group got converted to a universal one and the
> problem went away after that change had replicated to all DC.

Perfect.  Thanks for sharing the solution!


Corinna

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]