Shares with strange ACL settings

Shares with strange ACL settings

[Achim Gratz]

I've thought some more about those strange shares I need to use that have
inherited ACL that don't let me change the ACL at all and hence prevent
Cygwin from fixing up the POSIX permissions.  That generally ends up with
permissions like these:

% ll test
total 10
d---rwx---+ 1 gratz          Domain Users    0 Aug 10 11:51 ./
d---rwx---+ 1 Administrators Administrators  0 Aug 10 11:50 ../
----rwx---+ 1 gratz          Domain Users   18 Aug 10 11:51 blafasel*
----rwx---+ 1 gratz          Domain Users   18 Aug 10 11:51 blumblum*

Some applications that know how POSIX ACL are supposed to work conclude that
such directories or files are not readable:

% cd test
% perl -E 'say -r "." ? "readable" : "not readable";'
not readable
% perl -E 'say -r "blafasel" ? "readable" : "not readable";'
not readable

Other applications not using this shortcut and going all the way to
faccessat correctly determine readability:

% [ -r . ] && echo readable || echo not readable
readable
(1056)/mnt/upload/test > [ -r blafasel ] && echo readable || echo not readable
readable

If I access the files from another account (that has the same group
memberships that give read/write access to the share) or change the owner,
then the shortcut is never invoked:

$ perl -E 'say -r "." ? "readable" : "not readable";'
readable
$ perl -E 'say -r "blafasel" ? "readable" : "not readable";'
readable
$ [ -r . ] && echo readable || echo not readable
readable
$ [ -r blafasel ] && echo readable || echo not readable
readable

So, it would probably help if I had a mount option to force the ownership to
some account that I am never logged in as, either via a mount option or
whenever the POSIX user modes are all cleared.  I don't know if that might
confuse applications when they check ownership on newly created files,
though.  Is that something that is implementable easily so it could be
tested via a snapshot?


Regards,
Achim.



--
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: Shares with strange ACL settings

[Andrey Repin]

Greetings, Achim Gratz!

> I've thought some more about those strange shares I need to use that have
> inherited ACL that don't let me change the ACL at all and hence prevent
> Cygwin from fixing up the POSIX permissions.  That generally ends up with
> permissions like these:

> % ll test
> total 10
> d---rwx---+ 1 gratz          Domain Users    0 Aug 10 11:51 ./
> d---rwx---+ 1 Administrators Administrators  0 Aug 10 11:50 ../
> ----rwx---+ 1 gratz          Domain Users   18 Aug 10 11:51 blafasel*
> ----rwx---+ 1 gratz          Domain Users   18 Aug 10 11:51 blumblum*

> Some applications that know how POSIX ACL are supposed to work conclude that
> such directories or files are not readable:

> % cd test
> % perl -E 'say -r "." ? "readable" : "not readable";'

Perl is known to have "special" treatment of file permissions.
This issue has been raised in the list before.

> not readable
> % perl -E 'say -r "blafasel" ? "readable" : "not readable";'
> not readable

> Other applications not using this shortcut and going all the way to
> faccessat correctly determine readability:

> % [ -r . ] && echo readable || echo not readable
> readable
> (1056)/mnt/upload/test > [ -r blafasel ] && echo readable || echo not readable
> readable

> If I access the files from another account (that has the same group
> memberships that give read/write access to the share) or change the owner,
> then the shortcut is never invoked:

> $ perl -E 'say -r "." ? "readable" : "not readable";'
> readable
> $ perl -E 'say -r "blafasel" ? "readable" : "not readable";'
> readable
> $ [ -r . ] && echo readable || echo not readable
> readable
> $ [ -r blafasel ] && echo readable || echo not readable
> readable

> So, it would probably help if I had a mount option to force the ownership to
> some account that I am never logged in as, either via a mount option or
> whenever the POSIX user modes are all cleared.  I don't know if that might
> confuse applications when they check ownership on newly created files,
> though.  Is that something that is implementable easily so it could be
> tested via a snapshot?


-- 
With best regards,
Andrey Repin
Tuesday, August 11, 2015 20:04:58

Sorry for my terrible english...


--
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: Shares with strange ACL settings

[Achim Gratz]

Andrey Repin writes:
> Perl is known to have "special" treatment of file permissions.

It's perfectly valid to do this from a POSIX perspective and Perl is not
the only program to do this (but it's easier to show the result with
Perl).  As far as POSIX is concerned, the mode bits that Cygwin presents
are wrong given the actual access rights of the underlying Windows
DACL.

> This issue has been raised in the list before.

By me, so yes I know.  What's your point?


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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 11 08:42, Achim Gratz wrote:
> I've thought some more about those strange shares I need to use that have
> inherited ACL that don't let me change the ACL at all and hence prevent
> Cygwin from fixing up the POSIX permissions.  That generally ends up with
> permissions like these:
> 
> % ll test
> total 10
> d---rwx---+ 1 gratz          Domain Users    0 Aug 10 11:51 ./
> d---rwx---+ 1 Administrators Administrators  0 Aug 10 11:50 ../
> ----rwx---+ 1 gratz          Domain Users   18 Aug 10 11:51 blafasel*
> ----rwx---+ 1 gratz          Domain Users   18 Aug 10 11:51 blumblum*

I don't know what to do about this.  We're talking back and forth
about reflecting group perms into user perms and whether we do it
or not, it always seems to have some downside on some installations.

A reworked implementation which takes the exact user perms into account
in a Windows environment, and which works from a normal user account is
a major undertaking.  I doubt I'll have the time to implement something
big any time soon.

> Some applications that know how POSIX ACL are supposed to work conclude that
> such directories or files are not readable:
> 
> % cd test
> % perl -E 'say -r "." ? "readable" : "not readable";'
> not readable
> % perl -E 'say -r "blafasel" ? "readable" : "not readable";'
> not readable
> 
> Other applications not using this shortcut and going all the way to
> faccessat correctly determine readability:
> 
> % [ -r . ] && echo readable || echo not readable
> readable
> (1056)/mnt/upload/test > [ -r blafasel ] && echo readable || echo not readable
> readable
> 
> If I access the files from another account (that has the same group
> memberships that give read/write access to the share) or change the owner,
> then the shortcut is never invoked:
> 
> $ perl -E 'say -r "." ? "readable" : "not readable";'
> readable
> $ perl -E 'say -r "blafasel" ? "readable" : "not readable";'
> readable
> $ [ -r . ] && echo readable || echo not readable
> readable
> $ [ -r blafasel ] && echo readable || echo not readable
> readable
> 
> So, it would probably help if I had a mount option to force the ownership to
> some account that I am never logged in as, either via a mount option or
> whenever the POSIX user modes are all cleared.  I don't know if that might
> confuse applications when they check ownership on newly created files,
> though.  Is that something that is implementable easily so it could be
> tested via a snapshot?

I'm not sure I understand the idea of mounting w/ an explicit user account
and how this might help.  What about just using the noacl mount option
for weird shares like the above?


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> I don't know what to do about this.  We're talking back and forth
> about reflecting group perms into user perms and whether we do it
> or not, it always seems to have some downside on some installations.

Since there are fundamental differences between how Windows evaluates ACL
vs. what POSIX expects this problem isn't going away anytime soon. 
Depending on how much control you have over the default or inherited ACL you
can pretend these differences are non-existing with varying degrees of
success.  Another fly in that ointment are the Backup/Restore privileges,
but these you can control if you are aware of them.

> > So, it would probably help if I had a mount option to force the ownership to
> > some account that I am never logged in as, either via a mount option or
> > whenever the POSIX user modes are all cleared.  I don't know if that might
> > confuse applications when they check ownership on newly created files,
> > though.  Is that something that is implementable easily so it could be
> > tested via a snapshot?
> 
> I'm not sure I understand the idea of mounting w/ an explicit user account
> and how this might help.  What about just using the noacl mount option
> for weird shares like the above?

That mount option would ensure that the ACL are actually consulted by a
POSIX application when the user mode bits are all cleared since the file
would appear not to be owned by the (E)UID.  The only other option I can see
would be to augment stat to traverse the DACL when both these conditions are
met: the file is owned by the (E)UID of the calling process and the user
mode bits are all cleared.  That is, do the faccessat on behalf of the
application that it would otherwise (likely) do if the file was _not_ owned
by the user.  Of course you can't really know why stat was called and that
might impact perfromance quite noticeably.

As to "why not use the noacl option", that makes the file mode tests
completely useless and requires more elaborate error handling that would
otherwise not be necessary.  Some users and scripts they have written are
not prepared for that extra complication.


Regards,
Achim.



--
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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 12 15:50, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > I don't know what to do about this.  We're talking back and forth
> > about reflecting group perms into user perms and whether we do it
> > or not, it always seems to have some downside on some installations.
> 
> Since there are fundamental differences between how Windows evaluates ACL
> vs. what POSIX expects this problem isn't going away anytime soon. 
> Depending on how much control you have over the default or inherited ACL you
> can pretend these differences are non-existing with varying degrees of
> success.  Another fly in that ointment are the Backup/Restore privileges,
> but these you can control if you are aware of them.

Cygwin is aware of them and access(2) explicitely checks for them.  That
obviously doesn't help for applications like perl, who "know better"
than the underlying OS how to evaluate perms.

> > > So, it would probably help if I had a mount option to force the ownership to
> > > some account that I am never logged in as, either via a mount option or
> > > whenever the POSIX user modes are all cleared.  I don't know if that might
> > > confuse applications when they check ownership on newly created files,
> > > though.  Is that something that is implementable easily so it could be
> > > tested via a snapshot?
> > 
> > I'm not sure I understand the idea of mounting w/ an explicit user account
> > and how this might help.  What about just using the noacl mount option
> > for weird shares like the above?
> 
> That mount option would ensure that the ACL are actually consulted by a
> POSIX application when the user mode bits are all cleared since the file
> would appear not to be owned by the (E)UID.  The only other option I can see
> would be to augment stat to traverse the DACL when both these conditions are
> met: the file is owned by the (E)UID of the calling process and the user
> mode bits are all cleared.  That is, do the faccessat on behalf of the
> application that it would otherwise (likely) do if the file was _not_ owned
> by the user.  Of course you can't really know why stat was called and that
> might impact perfromance quite noticeably.

It does.  Another, *very* simple idea is this:  Spill the group and
other perms into the user bits only if the owner of the file is the
current user.  Would that help?

> As to "why not use the noacl option", that makes the file mode tests
> completely useless and requires more elaborate error handling that would
> otherwise not be necessary.  Some users and scripts they have written are
> not prepared for that extra complication.

But there's no additional checking necessary because the perms are
guarded by the OS anyway.  The applications just don't know them exactly.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen writes:
> Cygwin is aware of them and access(2) explicitely checks for them.  That
> obviously doesn't help for applications like perl, who "know better"
> than the underlying OS how to evaluate perms.

Perl is making use of an explicit guarantee in POSIX' ACL specification,
placed there in order to be backwards compatible to a system without
ACL.  Whether it is a good idea to do this is debatable of course and I
might hunt that code path down in Perl and squash it in some future
release.  It nevertheless is chink in Cygwin's shiny armor of "hey,
we're POSIX of the Linux flavor".

FWIW, Git seems to have an explicit check for POSIXPERMS in order to
sort out systems that don't conform exactly to that expectation.

> It does.  Another, *very* simple idea is this:  Spill the group and
> other perms into the user bits only if the owner of the file is the
> current user.  Would that help?

I think so, but there are likely some corner cases.  But I think that
had been proposed and shot down already, so I was trying to come up with
something less intrusive.

> But there's no additional checking necessary because the perms are
> guarded by the OS anyway.  The applications just don't know them exactly.

I have several scripts where tests for a readable file had to be
replaced with a test for non-zero-size file or just existing file.
Also, with the noacl option you'll always get a positive on most tests
and if the code is unprepared to handle the inevitable failure on the
actual access, then bad things can happen.  Not every piece of code has
already converted to the "let's try it and bail out when we get told to
get off" style of file access.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 12 20:09, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Cygwin is aware of them and access(2) explicitely checks for them.  That
> > obviously doesn't help for applications like perl, who "know better"
> > than the underlying OS how to evaluate perms.
> 
> Perl is making use of an explicit guarantee in POSIX' ACL specification,
> placed there in order to be backwards compatible to a system without
> ACL.  Whether it is a good idea to do this is debatable of course and I
> might hunt that code path down in Perl and squash it in some future
> release.  It nevertheless is chink in Cygwin's shiny armor of "hey,
> we're POSIX of the Linux flavor".
> 
> FWIW, Git seems to have an explicit check for POSIXPERMS in order to
> sort out systems that don't conform exactly to that expectation.
> 
> > It does.  Another, *very* simple idea is this:  Spill the group and
> > other perms into the user bits only if the owner of the file is the
> > current user.  Would that help?
> 
> I think so, but there are likely some corner cases.  But I think that
> had been proposed and shot down already, so I was trying to come up with
> something less intrusive.

This is relatively unintrusive.  The current user token is always
available.  So if owner == current user, for every group in the file's
ACL just check if it's in the current user token and, if so, add the
perms of that group to the owner perms.

Sounds pretty neat as an intermediate solution to me.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen writes:
>> I think so, but there are likely some corner cases.  But I think that
>> had been proposed and shot down already, so I was trying to come up with
>> something less intrusive.
>
> This is relatively unintrusive.  The current user token is always
> available.  So if owner == current user, for every group in the file's
> ACL just check if it's in the current user token and, if so, add the
> perms of that group to the owner perms.
>
> Sounds pretty neat as an intermediate solution to me.

I'd play the guinea pig for that snapshot… :-)


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 12 20:59, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> I think so, but there are likely some corner cases.  But I think that
> >> had been proposed and shot down already, so I was trying to come up with
> >> something less intrusive.
> >
> > This is relatively unintrusive.  The current user token is always
> > available.  So if owner == current user, for every group in the file's
> > ACL just check if it's in the current user token and, if so, add the
> > perms of that group to the owner perms.
> >
> > Sounds pretty neat as an intermediate solution to me.
> 
> I'd play the guinea pig for that snapshot… :-)

This puzzles me a bit.  As example you gave something like

  ----rwx---+ gratz Domain Users [...] foo

Given the code in recent Cygwin versions, this shouldn't happen if the
user gratz is member of the Domain Users group.  The current code
doesn't test all groups in the ACL, only the primary group, but that's
sufficient in most cases.

So this could only happen if you modify the permissions of windows files
using Cygwin tools and Cygwin helpfully gernerates a DENY ACE for the
owner.

I'm just not exactly sure about the way to go to get these permissions
in a non-artificial scenario.  But I can reproduce it like this:

- The file xxx has a primary group different from the group which has
  permissions, e.g.:

    owner:  foo
    pgroup: foo_group

    acl: 1 entry
      bar_group: full control

- ls -l xxx
  ----rwx---+ 1 foo foo_group 68565 Aug 10 10:37 xxx

- $ chmod g-w xxx

- Afterwards, the POSIX-like ACL looks like this:
  $ icacls xxx
  xxx foo:(DENY)(S,RD,REA,X)
      foo:(D,Rc,WDAC,WO,RA,WA)
      foo_group:(RX)
      Everyone:(Rc,S,RA)
      bar_group:(RX)

So, what's going on here and how do we really fix it?  It *might* be
prudent to drop any efforts to create DENY ACEs to reflect the POSIX
perms.  That results in the documented permission gap between POSIX and
Windows permissions, though.  There's just no way to express all possible
POSIX permissions using Windows ALLOW ACEs only.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen writes:
> This puzzles me a bit.  As example you gave something like
>
>   ----rwx---+ gratz Domain Users [...] foo
>
> Given the code in recent Cygwin versions, this shouldn't happen if the
> user gratz is member of the Domain Users group.  The current code
> doesn't test all groups in the ACL, only the primary group, but that's
> sufficient in most cases.

I've detailed the setup in an earlier post (with getfacl and icacls
output) that I can't dig out shortly, but the setup is, in a nutshell:

The share access is purely governed by two access groups, one that gives
you the right to read and another one that lets you create and change
things.  You'll be in one or both of these groups in AD.  All ACL are
inherited from the root of the share down and the right to change the
DACL (and thus remove that inheritance) is explicitly forbidden for
anybody.

The actual setup is a bit more complicated, with additional groups that
ensure that share administrators can do what they need to do and that
the backup can actually be done, etc.pp.

> So this could only happen if you modify the permissions of windows files
> using Cygwin tools and Cygwin helpfully gernerates a DENY ACE for the
> owner.

No, the owner just never gets the full access it would need to do this.
For a while they didn't even let you look at the DACL, but at least that
part of the silliness has been fixed.

> I'm just not exactly sure about the way to go to get these permissions
> in a non-artificial scenario.  But I can reproduce it like this:
>
> - The file xxx has a primary group different from the group which has
>   permissions, e.g.:
>
>     owner:  foo
>     pgroup: foo_group
>
>     acl: 1 entry
>       bar_group: full control
>
> - ls -l xxx
>   ----rwx---+ 1 foo foo_group 68565 Aug 10 10:37 xxx
>
> - $ chmod g-w xxx

The chmod, if you try to run it, never succeeds.  That's the crux of
this setup, anything will always have just rwx for the group via ACL and
you can't change that.

> So, what's going on here and how do we really fix it?  It *might* be
> prudent to drop any efforts to create DENY ACEs to reflect the POSIX
> perms.  That results in the documented permission gap between POSIX and
> Windows permissions, though.  There's just no way to express all possible
> POSIX permissions using Windows ALLOW ACEs only.

There aren't any deny ACL, you just don't get the right to play with the
permissions to start with.  FOr Windows it doesn't matter that the owner
hasn't got any access rights as long as she's in a group that has.
POSIX doesn't even look at the group/ACL if it the owner bits are
cleared.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

--
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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 13 18:33, Corinna Vinschen wrote:
> On Aug 12 20:59, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > >> I think so, but there are likely some corner cases.  But I think that
> > >> had been proposed and shot down already, so I was trying to come up with
> > >> something less intrusive.
> > >
> > > This is relatively unintrusive.  The current user token is always
> > > available.  So if owner == current user, for every group in the file's
> > > ACL just check if it's in the current user token and, if so, add the
> > > perms of that group to the owner perms.
> > >
> > > Sounds pretty neat as an intermediate solution to me.
> > 
> > I'd play the guinea pig for that snapshot… :-)
> 
> This puzzles me a bit.  As example you gave something like
> 
>   ----rwx---+ gratz Domain Users [...] foo
> 
> Given the code in recent Cygwin versions, this shouldn't happen if the
> user gratz is member of the Domain Users group.  The current code
> doesn't test all groups in the ACL, only the primary group, but that's
> sufficient in most cases.
> 
> So this could only happen if you modify the permissions of windows files
> using Cygwin tools and Cygwin helpfully gernerates a DENY ACE for the
> owner.
> 
> I'm just not exactly sure about the way to go to get these permissions
> in a non-artificial scenario.  But I can reproduce it like this:
> 
> - The file xxx has a primary group different from the group which has
>   permissions, e.g.:
> 
>     owner:  foo
>     pgroup: foo_group
> 
>     acl: 1 entry
>       bar_group: full control
> 
> - ls -l xxx
>   ----rwx---+ 1 foo foo_group 68565 Aug 10 10:37 xxx
> 
> - $ chmod g-w xxx
> 
> - Afterwards, the POSIX-like ACL looks like this:
>   $ icacls xxx
>   xxx foo:(DENY)(S,RD,REA,X)
>       foo:(D,Rc,WDAC,WO,RA,WA)
>       foo_group:(RX)
>       Everyone:(Rc,S,RA)
>       bar_group:(RX)

Oh, I get it.  This is *because* the current Cygwin doesn't check
membership of all groups in the ACL.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen writes:
> Cygwin is aware of them and access(2) explicitely checks for them.  That
> obviously doesn't help for applications like perl, who "know better"
> than the underlying OS how to evaluate perms.

Just for clarification, Perl doesn't "know better".  It's documented
that the file test operators only look at the mode bits and naver at the
ACL.  There's a pragma (use filetest qw/access/; # perldoc filetest)
that lets you use access for the tests instead, but it currently is an
unloved stepchild that doesn't let you use the stat cache (_) in tests
nor stacked file tests (-r -x), which use it.  The final nail in the
coffin is that with that pragma in effect you can only test filenames,
but not file handles.  So you really need to write your code from the
outset with that pragma in mind since it limits the use of test
operators so greatly.  At least they left the door open to a future
where the filetest pragma does something more sensible on systems that
rely to a larger extent on ACL.


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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 13 19:53, Corinna Vinschen wrote:
> On Aug 13 18:33, Corinna Vinschen wrote:
> > On Aug 12 20:59, Achim Gratz wrote:
> > > Corinna Vinschen writes:
> > > >> I think so, but there are likely some corner cases.  But I think that
> > > >> had been proposed and shot down already, so I was trying to come up with
> > > >> something less intrusive.
> > > >
> > > > This is relatively unintrusive.  The current user token is always
> > > > available.  So if owner == current user, for every group in the file's
> > > > ACL just check if it's in the current user token and, if so, add the
> > > > perms of that group to the owner perms.
> > > >
> > > > Sounds pretty neat as an intermediate solution to me.
> > > 
> > > I'd play the guinea pig for that snapshot… :-)
> > 
> > This puzzles me a bit.  As example you gave something like
> > [blah]
> Oh, I get it.  This is *because* the current Cygwin doesn't check
> membership of all groups in the ACL.

I checked in the change we were talking about.  Please give the latest
snapshot from https://cygwin.com/snapshots/ a try.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> I checked in the change we were talking about.  Please give the latest
> snapshot from https://cygwin.com/snapshots/ a try.

I've had a quick look and things look good.  I'll have to roll out the
snapshot to our server and revert the script changes, but it seems like this
should solve the problems I've had (and that forced noacl mounts in most
cases -- I've kept additional mounts without noacl for testing purposes that
will now come in handy).


Regards,
Achim.


--
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: Shares with strange ACL settings

[Corinna Vinschen]

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

Marco, please see below in terms of L3 cache info.  Thanks,

On Aug 14 10:56, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > I checked in the change we were talking about.  Please give the latest
> > snapshot from https://cygwin.com/snapshots/ a try.
> 
> I've had a quick look and things look good.  I'll have to roll out the
> snapshot to our server and revert the script changes, but it seems like this
> should solve the problems I've had (and that forced noacl mounts in most
> cases -- I've kept additional mounts without noacl for testing purposes that
> will now come in handy).

Cool, thanks for your quick feedback.

We should just be aware that this is ultimately a kludge.  I think I now
finally understand what would have to be done to get a generic solution
which results in correct POSIX permission evaluation for any current
user and any file ACL.  However, from some preliminary testing it seems
the generic solution has at least two downsides:

- It's slow (AuthZ code, setting up and breaking down user/group contexts
  for each checked file...)

- It would always contact the AD when trying to fetch info for AD users,
  which is bad for remote machines not or slowly connected to the AD server.

Anyway, this isn't pressing so it would be nice if you keep on testing.
I'm planning to update to 2.2.1 only after a certain pipe problem just
discussed on the #cygwin IRC channel is either fixed or settled any
other way, 

Btw., can you please also check /proc/cpuinfo?

As discussed, Cygwin's emulation fell short on L3 cache info.  I now
added code to fetch L3 cache info as well as correct processor topology
information on Intel CPUs.  For AMD CPUs the topology and cache
info was already fine.  Linux does not show L3 cache info for AMD CPUs
afaics, so I also didn't add that to Cygwin.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen writes:
> Cool, thanks for your quick feedback.

Thanks for the snapshot!

> We should just be aware that this is ultimately a kludge.  I think I now
> finally understand what would have to be done to get a generic solution
> which results in correct POSIX permission evaluation for any current
> user and any file ACL.  However, from some preliminary testing it seems
> the generic solution has at least two downsides:
>
> - It's slow (AuthZ code, setting up and breaking down user/group contexts
>   for each checked file...)
>
> - It would always contact the AD when trying to fetch info for AD users,
>   which is bad for remote machines not or slowly connected to the AD server.

I think we've came to the same conclusion (modulo the question of
whether AuthZ would be usable for this) some time ago.  My personal take
on this is that the "kludge" is likely better than both what we had
before and the result of the pre-snapshot ACL evaluation.  If that also
solves the problem of denying oneself file access by simply copying a
file with carefully crafted ACL, then I would say it's good enough for
most circumstances.  Probably not good enough to pass the Perl filemode
tests during build, but they have some problems in their design anyway.

> Anyway, this isn't pressing so it would be nice if you keep on
> testing.

As I said, I need some time next week to switch things into a mode where
problems could potentially show up.  I don't expect any, but I don't
pretend to understand all the edge cases completely either.

> I'm planning to update to 2.2.1 only after a certain pipe problem just
> discussed on the #cygwin IRC channel is either fixed or settled any
> other way, 
>
> Btw., can you please also check /proc/cpuinfo?

Yes, I have both AMD and Intel machines I can test this with.

> As discussed, Cygwin's emulation fell short on L3 cache info.  I now
> added code to fetch L3 cache info as well as correct processor topology
> information on Intel CPUs.  For AMD CPUs the topology and cache
> info was already fine.  Linux does not show L3 cache info for AMD CPUs
> afaics, so I also didn't add that to Cygwin.

I can't test this with a new enough kernel for AMD, but perhaps someone
is testing some new iron/OS combination and I can get that information
from them.  For Intel since some time the L3 cache size is shown (older
kernels would show you the per-node L2 cache size IIRC).


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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 14 20:25, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Btw., can you please also check /proc/cpuinfo?
> 
> Yes, I have both AMD and Intel machines I can test this with.
> 
> > As discussed, Cygwin's emulation fell short on L3 cache info.  I now
> > added code to fetch L3 cache info as well as correct processor topology
> > information on Intel CPUs.  For AMD CPUs the topology and cache
> > info was already fine.  Linux does not show L3 cache info for AMD CPUs
> > afaics, so I also didn't add that to Cygwin.
> 
> I can't test this with a new enough kernel for AMD, but perhaps someone
> is testing some new iron/OS combination and I can get that information
> from them.  For Intel since some time the L3 cache size is shown (older
> kernels would show you the per-node L2 cache size IIRC).

Recent kernels as well.  I just tested this with a 4.1.4 kernel, and the
source code of the upstream master branch shows no changes in terms of
the cache info on AMD CPUs.

A bit surprising, considering that the L3 cache info is apparently
available using the same CPUID leaf.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen writes:
> Btw., can you please also check /proc/cpuinfo?

The output is correct now for a SandyBridge dual-core CPU with
logical processors (aka HT) and an IvyBridge dual-core CPU w/o HT.

I've also tried to find out why the L3 cache is not reported for AMD in
cpuinfo.  It seems the reason is that it is logically part of the
northbridge system, even if it is on-die and gets reported via CPUID.


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

SD adaptation for Waldorf microQ V2.22R2:
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: Shares with strange ACL settings

[Marco Atzeri]

On 14/08/2015 15:45, Corinna Vinschen wrote:
> Marco, please see below in terms of L3 cache info.  Thanks,
>
[cut]
>
> Btw., can you please also check /proc/cpuinfo?
>
> As discussed, Cygwin's emulation fell short on L3 cache info.  I now
> added code to fetch L3 cache info as well as correct processor topology
> information on Intel CPUs.  For AMD CPUs the topology and cache
> info was already fine.  Linux does not show L3 cache info for AMD CPUs
> afaics, so I also didn't add that to Cygwin.
>

model name      : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
stepping        : 9
cpu MHz         : 2594.000
cache size      : 3072 KB

same L3 info as reported by

  $ hwloc-ls
Machine (4383MB total) + NUMANode L#0 (P#0 4383MB) + Package L#0 + L3 
L#0 (3072KB)
   L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
     PU L#0 (P#0)
     PU L#1 (P#1)
   L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1
     PU L#2 (P#2)
     PU L#3 (P#3)

> Thanks,
> Corinna

Regards
Marco


--
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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 15 17:11, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Btw., can you please also check /proc/cpuinfo?
> 
> The output is correct now for a SandyBridge dual-core CPU with
> logical processors (aka HT) and an IvyBridge dual-core CPU w/o HT.

Thanks!

> I've also tried to find out why the L3 cache is not reported for AMD in
> cpuinfo.  It seems the reason is that it is logically part of the
> northbridge system, even if it is on-die and gets reported via CPUID.

Ok, interesting.  Still strange, isn't it?


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 15 17:41, Marco Atzeri wrote:
> On 14/08/2015 15:45, Corinna Vinschen wrote:
> >Marco, please see below in terms of L3 cache info.  Thanks,
> >
> [cut]
> >
> >Btw., can you please also check /proc/cpuinfo?
> >
> >As discussed, Cygwin's emulation fell short on L3 cache info.  I now
> >added code to fetch L3 cache info as well as correct processor topology
> >information on Intel CPUs.  For AMD CPUs the topology and cache
> >info was already fine.  Linux does not show L3 cache info for AMD CPUs
> >afaics, so I also didn't add that to Cygwin.
> >
> 
> model name      : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
> stepping        : 9
> cpu MHz         : 2594.000
> cache size      : 3072 KB
> 
> same L3 info as reported by
> 
>  $ hwloc-ls
> Machine (4383MB total) + NUMANode L#0 (P#0 4383MB) + Package L#0 + L3 L#0
> (3072KB)
>   L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
>     PU L#0 (P#0)
>     PU L#1 (P#1)
>   L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1
>     PU L#2 (P#2)
>     PU L#3 (P#3)

Nice, thanks for testing!

Btw., I'm planning to add the sysconf cache output to 2.3.0, now that I
know how to do it.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen writes:
>> I've also tried to find out why the L3 cache is not reported for AMD in
>> cpuinfo.  It seems the reason is that it is logically part of the
>> northbridge system, even if it is on-die and gets reported via CPUID.
>
> Ok, interesting.  Still strange, isn't it?

In any case, it's not due to an inability to get at the cache sizes.
The code that fills those in has the sizes for all levels, but the cache
size structure that gets used in /proc/cpuinfo is filled from L2 on AMD
and L3 on Intel.  If you need the full information on Linux you'd go to
/sys/devices/system/cpu or use one of the more specialized programs that
give you topology information anyway.


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

--
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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 14 20:25, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Cool, thanks for your quick feedback.
> 
> Thanks for the snapshot!
> 
> > We should just be aware that this is ultimately a kludge.  I think I now
> > finally understand what would have to be done to get a generic solution
> > which results in correct POSIX permission evaluation for any current
> > user and any file ACL.  However, from some preliminary testing it seems
> > the generic solution has at least two downsides:
> >
> > - It's slow (AuthZ code, setting up and breaking down user/group contexts
> >   for each checked file...)
> >
> > - It would always contact the AD when trying to fetch info for AD users,
> >   which is bad for remote machines not or slowly connected to the AD server.
> 
> I think we've came to the same conclusion (modulo the question of
> whether AuthZ would be usable for this) some time ago.  My personal take
> on this is that the "kludge" is likely better than both what we had
> before and the result of the pre-snapshot ACL evaluation.

FYI, I revamped my AuthZ tests over the weekend and it's not *that*
slow, especially if the application caches and reuses AuthZ user
contexts fetched previosly.

I have POC code in my local sandbox, and I'm planning to apply this to
Cygwin after the 2.2.1 release.  I have some hopes that the AuthZ code
was the puzzle piece missing in the unified POSIX ACL handling code we
tested and then had to drop again earlier this year.

Stay tuned for another round of this unified POSIX ACL handling tests
later this year.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Achim Gratz <Stromeko <at> nexgo.de> writes:
> The output is correct now for a SandyBridge dual-core CPU with
> logical processors (aka HT) and an IvyBridge dual-core CPU w/o HT.

Another IvyBridge dual-core w/ HT looks also correct.

However, for the Piledriver Opteron 6328 in the 2012R2 server, Cygwin
reports 8 cores.  Linux on the other hand would report 8 processors on 4
cores (SMT, like HT on Intel).  I don't know where you get the topology
information from, but Windows' task manager reports 4 cores with 8 logical
processors and two NUMA nodes on this machine.

Regards,
Achim.


--
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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 17 08:27, Achim Gratz wrote:
> Achim Gratz <Stromeko <at> nexgo.de> writes:
> > The output is correct now for a SandyBridge dual-core CPU with
> > logical processors (aka HT) and an IvyBridge dual-core CPU w/o HT.
> 
> Another IvyBridge dual-core w/ HT looks also correct.
> 
> However, for the Piledriver Opteron 6328 in the 2012R2 server, Cygwin
> reports 8 cores.  Linux on the other hand would report 8 processors on 4
> cores (SMT, like HT on Intel).  I don't know where you get the topology
> information from,

The code is loosly based on what the Linux kernel does, combined with
the information given in

http://wiki.osdev.org/Detecting_CPU_Topology_%2880x86%29

So on AMD the topo is taken from cpuids 0x80000008 and 0x00000001,
but I may have made a mistake there.

[...digging...]

Oh, ok.  It seems I accidentally dropped a piece of code there.  Can you
do me a favor and run the following test application?  I just need the
value your Piledrive CPU returns in ecx returned by cpuid 0x80000008:

========================================================================
#include <stdio.h>
#include <stdint.h>

static inline void __attribute ((always_inline))
cpuid (uint32_t *a, uint32_t *b, uint32_t *c, uint32_t *d,
       uint32_t ain, uint32_t cin)
{
 asm volatile ("cpuid"
               : "=a" (*a), "=b" (*b), "=c" (*c), "=d" (*d)
               : "a" (ain), "c" (cin));
}

int
main ()
{
  uint32_t eax, ebx, ecx, edx;

  cpuid (&eax, &ebx, &ecx, &edx, 0x80000008, 0);
  printf ("0x80000008    %08x %08x %08x %08x\n", eax, ebx, ecx, edx);
}
========================================================================


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> Oh, ok.  It seems I accidentally dropped a piece of code there.  Can you
> do me a favor and run the following test application?  I just need the
> value your Piledrive CPU returns in ecx returned by cpuid 0x80000008:

Opteron 6328
0x80000008    00003030 00000000 00005007 00000000

For reference:
i5-3320M
0x80000008    00003024 00000000 00000000 00000000


Regards,
Achim.


--
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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 17 09:12, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > Oh, ok.  It seems I accidentally dropped a piece of code there.  Can you
> > do me a favor and run the following test application?  I just need the
> > value your Piledrive CPU returns in ecx returned by cpuid 0x80000008:
> 
> Opteron 6328
> 0x80000008    00003030 00000000 00005007 00000000

Thanks.  Can you please also show me the output of cpuid 0x8000001e?
Looks like newer AMDs provide additional topology info...


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> Thanks.  Can you please also show me the output of cpuid 0x8000001e?
> Looks like newer AMDs provide additional topology info...

Opteron 6328
0x80000008    00003030 00000000 00005007 00000000
0x8000001e    00000025 00000102 00000101 00000000

Core i5-3320M
0x80000008    00003024 00000000 00000000 00000000
0x8000001e    00000007 00000340 00000340 00000000


Regards,
Achim.


--
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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 17 10:51, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > Thanks.  Can you please also show me the output of cpuid 0x8000001e?
> > Looks like newer AMDs provide additional topology info...
> 
> Opteron 6328
> 0x80000008    00003030 00000000 00005007 00000000
> 0x8000001e    00000025 00000102 00000101 00000000

Sorry, forgot one :(.  What's the output of cpuid 0x00000001?


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> Sorry, forgot one :(.  What's the output of cpuid 0x00000001?

0x00000001? I've added 0x80000001 in case that was a typo.

Opteron 6328
0x00000001    00600f20 01080800 3e98320b 178bfbff
0x80000001    00600f20 30000000 01ebbfff 2fd3fbff
0x80000008    00003030 00000000 00005007 00000000
0x8000001e    00000021 00000100 00000100 00000000


Regards,
Achim.


--
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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 17 11:08, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > Sorry, forgot one :(.  What's the output of cpuid 0x00000001?
> 
> 0x00000001? I've added 0x80000001 in case that was a typo.

Heh, no, it wasn't :)

> Opteron 6328
> 0x00000001    00600f20 01080800 3e98320b 178bfbff
> 0x80000001    00600f20 30000000 01ebbfff 2fd3fbff
> 0x80000008    00003030 00000000 00005007 00000000
> 0x8000001e    00000021 00000100 00000100 00000000

Thank you,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 17 13:31, Corinna Vinschen wrote:
> On Aug 17 11:08, Achim Gratz wrote:
> > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > Sorry, forgot one :(.  What's the output of cpuid 0x00000001?
> > 
> > 0x00000001? I've added 0x80000001 in case that was a typo.
> 
> Heh, no, it wasn't :)
> 
> > Opteron 6328
> > 0x00000001    00600f20 01080800 3e98320b 178bfbff
> > 0x80000001    00600f20 30000000 01ebbfff 2fd3fbff
> > 0x80000008    00003030 00000000 00005007 00000000
> > 0x8000001e    00000021 00000100 00000100 00000000

Uhm... one last question?  What's the output of `lscpu'?


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> Uhm... one last question?  What's the output of `lscpu'?

Not available on Cygwin and I don't have access to a Linux box with that
processor.  I can ask, but it'll take some time.


Regards,
Achim.


--
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: Shares with strange ACL settings

[Achim Gratz]

Achim Gratz <Stromeko <at> NexGo.DE> writes:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > Uhm... one last question?  What's the output of `lscpu'?
> 
> Not available on Cygwin and I don't have access to a Linux box with that
> processor.  I can ask, but it'll take some time.

No Linux on bare metal with Bulldozer/Piledriver, only an older K10
MagnyCours / Opteron 6174:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                24
On-line CPU(s) list:   0-23
Thread(s) per core:    1
Core(s) per socket:    12
Socket(s):             2
NUMA node(s):          4
Vendor ID:             AuthenticAMD
CPU family:            16
Model:                 9
Stepping:              1
CPU MHz:               2200.091
BogoMIPS:              4400.10
Virtualization:        AMD-V
L1d cache:             64K
L1i cache:             64K
L2 cache:              512K
L3 cache:              5118K
NUMA node0 CPU(s):     0,2,4,6,8,10
NUMA node1 CPU(s):     12,14,16,18,20,22
NUMA node2 CPU(s):     1,3,5,7,9,11
NUMA node3 CPU(s):     13,15,17,19,21,23

I don't have access to that system, so unfortunately I can't run your program.


Regards,
Achim.


--
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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 17 12:42, Achim Gratz wrote:
> Achim Gratz <Stromeko <at> NexGo.DE> writes:
> > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > Uhm... one last question?  What's the output of `lscpu'?
> > 
> > Not available on Cygwin and I don't have access to a Linux box with that
> > processor.  I can ask, but it'll take some time.
> 
> No Linux on bare metal with Bulldozer/Piledriver, only an older K10
> MagnyCours / Opteron 6174:
> 
> Architecture:          x86_64
> CPU op-mode(s):        32-bit, 64-bit
> Byte Order:            Little Endian
> CPU(s):                24
> On-line CPU(s) list:   0-23
> Thread(s) per core:    1
> Core(s) per socket:    12
> Socket(s):             2
> NUMA node(s):          4
> Vendor ID:             AuthenticAMD
> CPU family:            16
> Model:                 9
> Stepping:              1
> CPU MHz:               2200.091
> BogoMIPS:              4400.10
> Virtualization:        AMD-V
> L1d cache:             64K
> L1i cache:             64K
> L2 cache:              512K
> L3 cache:              5118K
> NUMA node0 CPU(s):     0,2,4,6,8,10
> NUMA node1 CPU(s):     12,14,16,18,20,22
> NUMA node2 CPU(s):     1,3,5,7,9,11
> NUMA node3 CPU(s):     13,15,17,19,21,23
> 
> I don't have access to that system, so unfortunately I can't run your program.

No worries and thank you.  I just don't quite understand the stuff
returned by 8000001e and what I see above.  Do I understand this
correctly that a single CPU has 2 NUMA nodes?  Does that mean a single
HW socket consists of two independent 6 core CPUs?

Well, anyway, I just got remote access to a 2 socket systems with
Opteron 6386SE CPUs. It's installing rhel7 right now so I might get
another clue from there.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

> No worries and thank you.  I just don't quite understand the stuff
> returned by 8000001e and what I see above.

Different architectures, so these are not expected to match.

>  Do I understand this
> correctly that a single CPU has 2 NUMA nodes?  Does that mean a single
> HW socket consists of two independent 6 core CPUs?

In the case above, yes.  MagnyCours is two Istanbul dies in one package.

> Well, anyway, I just got remote access to a 2 socket systems with
> Opteron 6386SE CPUs. It's installing rhel7 right now so I might get
> another clue from there.

Yes, that should help.  That's again two dies per package, each with 8
processors paired inside 4 modules.  Each of the two die should be more or
less identical to the 6328, save for clock frequency.


Regards,
Achim.


--
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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 17 13:12, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> 
> > No worries and thank you.  I just don't quite understand the stuff
> > returned by 8000001e and what I see above.
> 
> Different architectures, so these are not expected to match.

Sure, I wasn't expecting that.  I referred to the cpuid output you
provided and the matching info from your OP starting this subthread.

> >  Do I understand this
> > correctly that a single CPU has 2 NUMA nodes?  Does that mean a single
> > HW socket consists of two independent 6 core CPUs?
> 
> In the case above, yes.  MagnyCours is two Istanbul dies in one package.
> 
> > Well, anyway, I just got remote access to a 2 socket systems with
> > Opteron 6386SE CPUs. It's installing rhel7 right now so I might get
> > another clue from there.
> 
> Yes, that should help.  That's again two dies per package, each with 8
> processors paired inside 4 modules.  Each of the two die should be more or
> less identical to the 6328, save for clock frequency.

Indeed, looking into the output provided by the 6328SE and some 12 core
MagnyCours CPU I forgot the number of, was helpful.  I *think* I fixed
the cpuinfo now for new AMDs which provide 0x800001e topology info.

Please give the latest snapshot from https://cygwin.com/snapshots/
a try.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Shares with strange ACL settings

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> Please give the latest snapshot from https://cygwin.com/snapshots/
> a try.

Looks good:
32bit (1001)~ > cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 21
model           : 2
model name      : AMD Opteron(tm) Processor 6328
stepping        : 0
cpu MHz         : 3200.000
cache size      : 2048 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm
sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce
nodeid_msr tbm topoext perfctr_core perfctr_nb
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 21
model           : 2
model name      : AMD Opteron(tm) Processor 6328
stepping        : 0
cpu MHz         : 3200.000
cache size      : 2048 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm
sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce
nodeid_msr tbm topoext perfctr_core perfctr_nb
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

processor       : 2
vendor_id       : AuthenticAMD
cpu family      : 21
model           : 2
model name      : AMD Opteron(tm) Processor 6328
stepping        : 0
cpu MHz         : 3200.000
cache size      : 2048 KB
physical id     : 0
siblings        : 8
core id         : 1
cpu cores       : 4
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm
sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce
nodeid_msr tbm topoext perfctr_core perfctr_nb
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

processor       : 3
vendor_id       : AuthenticAMD
cpu family      : 21
model           : 2
model name      : AMD Opteron(tm) Processor 6328
stepping        : 0
cpu MHz         : 3200.000
cache size      : 2048 KB
physical id     : 0
siblings        : 8
core id         : 1
cpu cores       : 4
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm
sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce
nodeid_msr tbm topoext perfctr_core perfctr_nb
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

processor       : 4
vendor_id       : AuthenticAMD
cpu family      : 21
model           : 2
model name      : AMD Opteron(tm) Processor 6328
stepping        : 0
cpu MHz         : 3200.000
cache size      : 2048 KB
physical id     : 0
siblings        : 8
core id         : 2
cpu cores       : 4
apicid          : 4
initial apicid  : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm
sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce
nodeid_msr tbm topoext perfctr_core perfctr_nb
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

processor       : 5
vendor_id       : AuthenticAMD
cpu family      : 21
model           : 2
model name      : AMD Opteron(tm) Processor 6328
stepping        : 0
cpu MHz         : 3200.000
cache size      : 2048 KB
physical id     : 0
siblings        : 8
core id         : 2
cpu cores       : 4
apicid          : 5
initial apicid  : 5
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm
sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce
nodeid_msr tbm topoext perfctr_core perfctr_nb
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

processor       : 6
vendor_id       : AuthenticAMD
cpu family      : 21
model           : 2
model name      : AMD Opteron(tm) Processor 6328
stepping        : 0
cpu MHz         : 3200.000
cache size      : 2048 KB
physical id     : 0
siblings        : 8
core id         : 3
cpu cores       : 4
apicid          : 6
initial apicid  : 6
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm
sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce
nodeid_msr tbm topoext perfctr_core perfctr_nb
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

processor       : 7
vendor_id       : AuthenticAMD
cpu family      : 21
model           : 2
model name      : AMD Opteron(tm) Processor 6328
stepping        : 0
cpu MHz         : 3200.000
cache size      : 2048 KB
physical id     : 0
siblings        : 8
core id         : 3
cpu cores       : 4
apicid          : 7
initial apicid  : 7
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm
sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce
nodeid_msr tbm topoext perfctr_core perfctr_nb
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro


Regards,
Achim.


--
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: Shares with strange ACL settings

[Corinna Vinschen]

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

On Aug 17 15:47, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > Please give the latest snapshot from https://cygwin.com/snapshots/
> > a try.
> 
> Looks good:
> 32bit (1001)~ > cat /proc/cpuinfo
> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 21
> model           : 2
> model name      : AMD Opteron(tm) Processor 6328
> stepping        : 0
> cpu MHz         : 3200.000
> cache size      : 2048 KB
> physical id     : 0
> siblings        : 8
> core id         : 0
> cpu cores       : 4
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 13
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
> pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm
> sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce
> nodeid_msr tbm topoext perfctr_core perfctr_nb
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 48 bits physical, 48 bits virtual
> power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro
                                                   ^^^^^^^^^^^^^^^
And those work too, cool.


Thanks for testing,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]