[TESTERS needed] New POSIX permission handling

[TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

Hi folks,


I just applied a patch I'm working on for quite some time now.  As I
outlined before on this list, the POSIX permission handling has aged
considerably and, for historical reasons, did things differently
dependent on the calling function.  I took the time to reimplement the
core functionality to handle all ACLs as strictly following POSIX ACL
rules as possible.

Cygwin now generates ACLs in a certain way, always following the same
construction rules.  The new ACLs are always recognizable as Cygwin
ACLs.  The always start with an Access-Denied ACE for the NULL SID with
certain bits set.  Any ACL not starting this way is handled as a
non-Cygwin or "old style" ACL, but still trying to evaluate the ACL as
strictly following POSIX rules as possible.

Two other noticable changes from before:

- To accommodate Windows default ACLs, the new code ignores SYSTEM and
  Administrators group permissions when computing the MASK/CLASS_OBJ
  permission mask on old ACLs, and it doesn't deny access to SYSTEM and
  Administrators group based on the value of MASK/CLASS_OBJ when
  creating the new ACLs.

  That means, even if SYSTEM or Administrators have full access to the
  file, the POSIX permssion bits will not reflect that fact.  And while
  other users get access denied based on the mask value, SYSTEM and
  Administrators will never get access denied based on the mask.

  This should help in Cygwin<->Windows interoperability.

- The new code now handles the S_ISGID bit on directories as on Linux:
  Setting S_ISGID on a directory causes new files and subdirs created
  within to inherit its group, rather than the primary group of the user
  who created the file.

  But note that this only works for files and directories created by
  Cygwin processes.  The group change is not supported automagically by
  Windows, so the process creating the new file has to change the file
  group silenmtly after creating the file.

Apart from bugfixing the aforementioned code, there's still work to do
on the getfacl and setfacl tools:

- The getfacl tool needs an extension in output to print the effective
  permissions on users and groups restricted by the mask value.

- The setfacl tool needs code to compute the new mask value, just as
  on Linux.

I'm looking into that next week.

Please give the new code a try.  I uploaded new 2015-04-10 developer
snapshots to https://cygwin.com/snapshots/

Probably next week I will also create a test release which can be
installed via setup-x86{_64}.exe.


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: [TESTERS needed] New POSIX permission handling

[Warren Young]

On Apr 10, 2015, at 4:07 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
>  This should help in Cygwin<->Windows interoperability.

That’s pretty vague.

Would you care to list some specific expected improvements from this change?  Are there known problem scenarios in the current world which we can test both ways, which should behave differently under the new DLL?

For instance, does it fix the well-known problem with chmod 600 ~/.ssh/* resulting in mode 660 until you kick the ACLs around a bit?
--
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: [TESTERS needed] New POSIX permission handling

[Steven Penny]

On Fri, Apr 10, 2015 at 5:07 AM, Corinna Vinschen wrote:
> Please give the new code a try.  I uploaded new 2015-04-10 developer
> snapshots to https://cygwin.com/snapshots/

Here is the test I ran:

    $ cd /cygdrive/c

    $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh

    $ chmod +x ~/bravo.sh ~+/delta.sh

    $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
    -rw-rw-r--+ 1 John None 0 Apr 10 16:51 /cygdrive/c/charlie.sh
    -rwxrwxr-x+ 1 John None 0 Apr 10 16:51 /cygdrive/c/delta.sh    (green)
    -rw-r--r--  1 John None 0 Apr 10 16:51 /home/John/alpha.sh
    -rwxrwxr-x  1 John None 0 Apr 10 16:51 /home/John/bravo.sh     (green)

So "charlie.sh" looks strange because it has that extra write permission.
However this is not a big deal for me. My concern was that everything was
showing up executable (green) when running "ls --color". So overall this is an
improvement, thanks.

--
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: [TESTERS needed] New POSIX permission handling

[Achim Gratz]

Corinna Vinschen writes:
> - To accommodate Windows default ACLs, the new code ignores SYSTEM and
>   Administrators group permissions when computing the MASK/CLASS_OBJ
>   permission mask on old ACLs, and it doesn't deny access to SYSTEM and
>   Administrators group based on the value of MASK/CLASS_OBJ when
>   creating the new ACLs.

Since you've now opened that can of worms of who is considered "root",
what about "Domain Administrators" or "Power Users", for starters?

>   That means, even if SYSTEM or Administrators have full access to the
>   file, the POSIX permssion bits will not reflect that fact.  And while
>   other users get access denied based on the mask value, SYSTEM and
>   Administrators will never get access denied based on the mask.

If you want to put this to better use in larger settings it would seem
preferrable if it was possible to define a list of users to treat this
way in fstab.  I think this would help with the braindead settings
NetApp filers are set up these days by default.  That generally means
that some domain group(s) need to be considered root on the share
depending on which share you are accessing.

> Apart from bugfixing the aforementioned code, there's still work to do
> on the getfacl and setfacl tools:

Sorry to pile another one on here: Currently it's not possible to use -k
and -b on the same invocation.  This works just fine on Linux.

Having the newer getfacl / setfacl from *BSD that deals with NFSv4 ACL
might be worth a shot, since at least superficially these seem to match
better to NTFS DACL in scope and would probably bring it more in line
with what icacls would show and do.  Before you ask, it has been duly
noted that NFSv4 ACL are somewhat incompatible with POSIX ACL in the
same way that NTFS DACL are… maybe some more info can be gleaned from
those documents:

http://users.suse.com/~agruen/acl/linux-acls/online/
http://users.suse.com/~agruen/nfs4acl/
http://www.ietf.org/archive/id/draft-ietf-nfsv4-acl-mapping-03.txt
http://www.bestbits.at/richacl/draft-gruenbacher-nfsv4-acls-in-posix-00.html
http://docs.oracle.com/cd/E23824_01/html/821-1448/gbacb.html


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: [TESTERS needed] New POSIX permission handling

[David Macek]

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

On 11. 4. 2015 10:47, Achim Gratz wrote:
> Corinna Vinschen writes:
>> - To accommodate Windows default ACLs, the new code ignores SYSTEM and
>>   Administrators group permissions when computing the MASK/CLASS_OBJ
>>   permission mask on old ACLs, and it doesn't deny access to SYSTEM and
>>   Administrators group based on the value of MASK/CLASS_OBJ when
>>   creating the new ACLs.

Out of curiosity, does the code somehow distinguish ACLs that don't have these default permissions (or have different permissions set for SYSTEM / Administrators)?

> Since you've now opened that can of worms of who is considered "root",
> what about "Domain Administrators" or "Power Users", for starters?
>
>>   That means, even if SYSTEM or Administrators have full access to the
>>   file, the POSIX permssion bits will not reflect that fact.  And while
>>   other users get access denied based on the mask value, SYSTEM and
>>   Administrators will never get access denied based on the mask.
> 
> If you want to put this to better use in larger settings it would seem
> preferrable if it was possible to define a list of users to treat this
> way in fstab.  I think this would help with the braindead settings
> NetApp filers are set up these days by default.  That generally means
> that some domain group(s) need to be considered root on the share
> depending on which share you are accessing.

Power Users don't have access to (almost) everything, like Administrators do. The Domain Administrators group is a member of Administrators, so unless I'm missing something, there's no reason to have them explicitely in the DACL. I'm not arguing against configurability though.

-- 
David Macek


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4234 bytes --]

Re: [TESTERS needed] New POSIX permission handling

[Achim Gratz]

David Macek writes:
> Power Users don't have access to (almost) everything, like
> Administrators do. The Domain Administrators group is a member of
> Administrators, so unless I'm missing something, there's no reason to
> have them explicitely in the DACL.

That doesn't stop folks from using them in DACL entries and membership
of one group in another (rightly) doesn't confer transitive access
rights.  I've just named these two examples because I've seen them
before in ACL, I make no claim as to whether that's a sensible thing to
do or not.


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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 10 15:13, Warren Young wrote:
> On Apr 10, 2015, at 4:07 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> > 
> >  This should help in Cygwin<->Windows interoperability.
> 
> That’s pretty vague.
> 
> Would you care to list some specific expected improvements from this
> change?  Are there known problem scenarios in the current world which
> we can test both ways, which should behave differently under the new
> DLL?
> 
> For instance, does it fix the well-known problem with chmod 600
> ~/.ssh/* resulting in mode 660 until you kick the ACLs around a bit?

Yes.  This has been discussed and I was originally opposing this change,
but not very loudly.  Other than that, please read the archives. You'll
find the threads discussing this in the last two months.


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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 10 19:00, Steven Penny wrote:
> On Fri, Apr 10, 2015 at 5:07 AM, Corinna Vinschen wrote:
> > Please give the new code a try.  I uploaded new 2015-04-10 developer
> > snapshots to https://cygwin.com/snapshots/
> 
> Here is the test I ran:
> 
>     $ cd /cygdrive/c
> 
>     $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
> 
>     $ chmod +x ~/bravo.sh ~+/delta.sh
> 
>     $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
>     -rw-rw-r--+ 1 John None 0 Apr 10 16:51 /cygdrive/c/charlie.sh
>     -rwxrwxr-x+ 1 John None 0 Apr 10 16:51 /cygdrive/c/delta.sh    (green)
>     -rw-r--r--  1 John None 0 Apr 10 16:51 /home/John/alpha.sh
>     -rwxrwxr-x  1 John None 0 Apr 10 16:51 /home/John/bravo.sh     (green)
> 
> So "charlie.sh" looks strange because it has that extra write permission.
> However this is not a big deal for me. My concern was that everything was
> showing up executable (green) when running "ls --color". So overall this is an
> improvement, thanks.

What is '~+'?  Is that some weird bash feature?

Did you check the ACL?  The ACL before and after the change should
explain what happened.  Check it with getfacl *and* icacls to get
an idea what it looks like, and compare the result with the POSIX
ACL rules, as outlined on, e.g., http://linux.die.net/man/5/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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 11 10:47, Achim Gratz wrote:
> Corinna Vinschen writes:
> > - To accommodate Windows default ACLs, the new code ignores SYSTEM and
> >   Administrators group permissions when computing the MASK/CLASS_OBJ
> >   permission mask on old ACLs, and it doesn't deny access to SYSTEM and
> >   Administrators group based on the value of MASK/CLASS_OBJ when
> >   creating the new ACLs.
> 
> Since you've now opened that can of worms of who is considered "root",
> what about "Domain Administrators" or "Power Users", for starters?

Nope.  The special handling for SYSTEM and Admins will help for the
default permission settings on Windows filesystems, and it won't
negatively influence the ACL mask handling.

> >   That means, even if SYSTEM or Administrators have full access to the
> >   file, the POSIX permssion bits will not reflect that fact.  And while
> >   other users get access denied based on the mask value, SYSTEM and
> >   Administrators will never get access denied based on the mask.
> 
> If you want to put this to better use in larger settings it would seem
> preferrable if it was possible to define a list of users to treat this
> way in fstab.

Nope, sorry, no configuration for this.  Either it's handled without
any exception, or for SYSTEM only, or for SYSTEM+Admins.  But either
way, we're doing it the same way on every system.

> Sorry to pile another one on here: Currently it's not possible to use -k
> and -b on the same invocation.  This works just fine on Linux.

I'm not planning to work on this, but as for other parts of Cygwin,
I do take patches.

> Having the newer getfacl / setfacl from *BSD that deals with NFSv4 ACL
> might be worth a shot,

ACL handling on Cygwin is POSIX ACL handling.  Either that or you set
"noacl" and use Windows tools.


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: [TESTERS needed] New POSIX permission handling

[David Macek]

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

On 11. 4. 2015 11:08, Achim Gratz wrote:
> David Macek writes:
>> Power Users don't have access to (almost) everything, like
>> Administrators do. The Domain Administrators group is a member of
>> Administrators, so unless I'm missing something, there's no reason to
>> have them explicitely in the DACL.
> 
> That doesn't stop folks from using them in DACL entries and membership
> of one group in another (rightly) doesn't confer transitive access
> rights.  I've just named these two examples because I've seen them
> before in ACL, I make no claim as to whether that's a sensible thing to
> do or not.

https://technet.microsoft.com/en-us/library/cc776499(v=ws.10).aspx says otherwise about the group-in-group rights. I'm a bit confused. Maybe we're talking about different things -- of course it makes sense to give Domain Administrators more rights than Administrators, but I don't see any reason for blanket granting Domain Administrators explicit rights on everything on the filesystem.

The way I see it, the point of the code change was to prevent the "implicit" Administrators and SYSTEM DACL entries from showing up in the computed POSIX access mask because they nicely match the implicit rights root accounts have on POSIX systems and because they're unhelpful and sometimes problematic. As neither Domain Administrators nor Power Users have this combination of properties (presence on most filesystem objects by default and SeTakeOwnershipPrivilege), I think it's useful to have them appear in the mask.

Please correct me if I'm talking nonsense; I have little practical experience with domain environments.

-- 
David Macek


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4234 bytes --]

Re: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 11 11:01, David Macek wrote:
> On 11. 4. 2015 10:47, Achim Gratz wrote:
> > Corinna Vinschen writes:
> >> - To accommodate Windows default ACLs, the new code ignores SYSTEM and
> >>   Administrators group permissions when computing the MASK/CLASS_OBJ
> >>   permission mask on old ACLs, and it doesn't deny access to SYSTEM and
> >>   Administrators group based on the value of MASK/CLASS_OBJ when
> >>   creating the new ACLs.
> 
> Out of curiosity, does the code somehow distinguish ACLs that don't
> have these default permissions (or have different permissions set for
> SYSTEM / Administrators)?

I don't quite understand the question.

For a start, I'd like to point out how POSIX ACLs are supposed to work.
http://linux.die.net/man/5/acl is a good start.  This is our role model.

What this new code in Cygwin does is to ignore SYSTEM and Administrators
account in a very specific way:  It ignores both accounts in terms of
the MASK (or CLASS_OBJ in Solaris speak) values in both directions:

- The "new style" ACLs contain an explicit MASK/CLASS_OBJ value.

  If the MASK/CLASS_OBJ value only allows rw- permissions, but a
  secondary user or group account has rwx permissions, Cygwin will
  generate an --x DENY ACE for this group.

  The exception here:  It won't generate this DENY for SYSTEM and
  Administrators.  So even if MASK disallows certain access, SYSTEM and
  Administrators are not affected but get their full set of permssions
  granted by the user or inheritance rules.

- The "old style" ACLs (created by native Windows means or by former
  Cygwin versions) don't have an explicit MASK.  The new Cygwin code
  generates a MASK value on the fly while reading the ACL.  This mask
  value is refelected by the group permission bits in the POSIX
  permission mask.  Since SYSTEM and Administrators often have "Full
  Access" to any object on the filesystem, that means that very often,
  the group permissions are "rwx", because the MASK value is "rwx".

  The new code will compute the mask the same way as before, but it
  skips the permissions of SYSTEM and Administrators while doing that.
  That means, the POSIX group permission bits are not affected by
  the Windows-typical permissions of SYSTEM and Administrators.

  Example:

    User            rw-
    Primary group   r--
    Other user      rw-
    Other group     r--
    SYSTEM          rwx
    Everyone        ---

  The computed POSIX MASK/CLASS_OBJ value in Cygwin 1.7.35 is the sum
  of all group and secondary user permissions

    rw- | r-- | rwx == rwx

  The new code ignores SYSTEM, thus the mask is

    rw- | r-- == rw-
     
Does this explain it sufficiently?


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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 11 11:40, Corinna Vinschen wrote:
> On Apr 10 19:00, Steven Penny wrote:
> > On Fri, Apr 10, 2015 at 5:07 AM, Corinna Vinschen wrote:
> > > Please give the new code a try.  I uploaded new 2015-04-10 developer
> > > snapshots to https://cygwin.com/snapshots/
> > 
> > Here is the test I ran:
> > 
> >     $ cd /cygdrive/c
> > 
> >     $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
> > 
> >     $ chmod +x ~/bravo.sh ~+/delta.sh
> > 
> >     $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
> >     -rw-rw-r--+ 1 John None 0 Apr 10 16:51 /cygdrive/c/charlie.sh
> >     -rwxrwxr-x+ 1 John None 0 Apr 10 16:51 /cygdrive/c/delta.sh    (green)
> >     -rw-r--r--  1 John None 0 Apr 10 16:51 /home/John/alpha.sh
> >     -rwxrwxr-x  1 John None 0 Apr 10 16:51 /home/John/bravo.sh     (green)
> > 
> > So "charlie.sh" looks strange because it has that extra write permission.
> > However this is not a big deal for me. My concern was that everything was
> > showing up executable (green) when running "ls --color". So overall this is an
> > improvement, thanks.
> 
> What is '~+'?  Is that some weird bash feature?
> 
> Did you check the ACL?  The ACL before and after the change should
> explain what happened.  Check it with getfacl *and* icacls to get
> an idea what it looks like, and compare the result with the POSIX
> ACL rules, as outlined on, e.g., http://linux.die.net/man/5/acl.

On second thought, what you need to know is what the NULL DENY ACE looks
like when looking at it in icacls.

The following bits in the NULL DENY access mask are used:

  Windows access    <->   POSIX access
  --------------          ------------
  FILE_READ_DATA          S_ISVTX
  FILE_WRITE_DATA         S_ISGID
  FILE_APPEND_DATA        S_ISUID

  FILE_READ_EA            MASK S_IXOTH  (POSIX execute perms)
  FILE_WRITE_EA           MASK S_IWOTH  (POSIX write perms)
  FILE_EXECUTE            MASK S_IROTH  (POSIX read perms)

  FILE_DELETE_CHILD       Set if MASK is valid

  READ_CONTROL            Set to mark this as a "new style" ACL.

  SYNCHRONIZE             Has no meaning, but icacls has a bug in
                          printing the access mask of DENY ACEs.

Same bits are used in the inheritable NULL DENY, but S_ISVTX and S_ISUID
should never be set, because they are not supposed to be inherited,


HTH,
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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 11 11:40, Corinna Vinschen wrote:
> On Apr 10 19:00, Steven Penny wrote:
> > On Fri, Apr 10, 2015 at 5:07 AM, Corinna Vinschen wrote:
> > > Please give the new code a try.  I uploaded new 2015-04-10 developer
> > > snapshots to https://cygwin.com/snapshots/
> > 
> > Here is the test I ran:
> > 
> >     $ cd /cygdrive/c
> > 
> >     $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
> > 
> >     $ chmod +x ~/bravo.sh ~+/delta.sh
> > 
> >     $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
> >     -rw-rw-r--+ 1 John None 0 Apr 10 16:51 /cygdrive/c/charlie.sh
> >     -rwxrwxr-x+ 1 John None 0 Apr 10 16:51 /cygdrive/c/delta.sh    (green)
> >     -rw-r--r--  1 John None 0 Apr 10 16:51 /home/John/alpha.sh
> >     -rwxrwxr-x  1 John None 0 Apr 10 16:51 /home/John/bravo.sh     (green)
> > 
> > So "charlie.sh" looks strange because it has that extra write permission.
> > However this is not a big deal for me. My concern was that everything was
> > showing up executable (green) when running "ls --color". So overall this is an
> > improvement, thanks.
> 
> What is '~+'?  Is that some weird bash feature?
> 
> Did you check the ACL?  The ACL before and after the change should
> explain what happened.

Oh, sorry, you're createsing new files, so there's no before/after.  In
that case the result in the group permission is based on the MASK value
generated as a result of permission inhertance rules.  So what you
should check is the parent descriptor and look at the inheritable ACEs
(default ACL entries in POSIX speak) and compare them with the
permissions Xof the newly created files.

> Check it with getfacl *and* icacls to get
> an idea what it looks like, and compare the result with the POSIX
> ACL rules, as outlined on, e.g., http://linux.die.net/man/5/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: [TESTERS needed] New POSIX permission handling

[Steven Penny]

On Sat, Apr 11, 2015 at 4:40 AM, Corinna Vinschen wrote:
> What is '~+'?  Is that some weird bash feature?

If the tilde-prefix is ‘~+’, the value of the shell variable PWD replaces the
tilde-prefix.

http://gnu.org/software/bash/manual/html_node/Tilde-Expansion

--
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: [TESTERS needed] New POSIX permission handling

[Bryan Berns]

>> >   That means, even if SYSTEM or Administrators have full access to the
>> >   file, the POSIX permssion bits will not reflect that fact.  And while
>> >   other users get access denied based on the mask value, SYSTEM and
>> >   Administrators will never get access denied based on the mask.
>>
>> If you want to put this to better use in larger settings it would seem
>> preferrable if it was possible to define a list of users to treat this
>> way in fstab.
>
> Nope, sorry, no configuration for this.  Either it's handled without
> any exception, or for SYSTEM only, or for SYSTEM+Admins.  But either
> way, we're doing it the same way on every system.

Damn.  I was about to reply with Achim's exact same thought --- like a
file in /etc with a list of SIDs.  I can empathize with Corinna's veto
though -- having a hundred tweak-able settings in Cygwin is
unmaintainable for the general populous.  I may apply a local patch to
extend this ability myself because Cygwin has become rather unusable
for users with home's on our network drives (given all the programs
that attempt to do sanity checks on group perms).

That said, I appreciate what has been integrated --- it will help in
several scenarios.  I will test the release this weekend.  Thanks for
all the hard work!

--
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: [TESTERS needed] New POSIX permission handling

[Achim Gratz]

David Macek writes:
> https://technet.microsoft.com/en-us/library/cc776499(v=ws.10).aspx
> says otherwise about the group-in-group rights.

As I see it, nesting groups is just a more efficient way of populating
them, so by expanding the nested groups recursively you'll end up with
the effective set of users that have those rights.  But if I have a DACL
permission for "Domain Admins" that still doesn't mean that
"Administrators" (the group) gets access.  The other way around
(intentionally) works, by virtue of "Domain Admins" being a member of
"Administrators".  Also, "Administrator" (the account) is by default a
member of both "Administrators" and "Domain Administrators", which is a
bit confusing.

> The way I see it, the point of the code change was to prevent the
> "implicit" Administrators and SYSTEM DACL entries from showing up in
> the computed POSIX access mask because they nicely match the implicit
> rights root accounts have on POSIX systems and because they're
> unhelpful and sometimes problematic.

My point is that the interpretation of who gets to call himself "root"
in that analogy is quite fuzzy and sometimes depends on the filesystem
you look at.  The choice proffered by Cygwin now is mostly correct for
local file systems, but not necessarily for network shares (and most
certainly not for a few important ones I'll have to deal with).

The fallback will be to mount with "noacl" as before, something I had
hoped would no longer be necessary.  I have a few applications where the
faked file modes simply don't cut it and so far I've been lucky that
either the shares these need to be on are configured differently by
default (like my home "drive") or I could convince IT to give me
something non-standard.  But the next round of filer or server upgrades
or changed security policies might leave me stranded, so I'm really not
too keen to rely on that indefinitely.

> As neither Domain Administrators nor Power Users have this combination
> of properties (presence on most filesystem objects by default and
> SeTakeOwnershipPrivilege), I think it's useful to have them appear in
> the mask.

For isolated systems and small networks, this is wholly sufficient.
Large networked installations have, for better or worse, more
complicated setups.  Again, I see a lot of cruft that likely wouldn't be
necessary and is probably largely historical, but some of it really
can't be changed.


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: [TESTERS needed] New POSIX permission handling

[David Macek]

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

On 11. 4. 2015 11:59, Corinna Vinschen wrote:
>> Out of curiosity, does the code somehow distinguish ACLs that don't
>> have these default permissions (or have different permissions set for
>> SYSTEM / Administrators)?
> 
> I don't quite understand the question.
> 
> For a start, I'd like to point out how POSIX ACLs are supposed to work.
> http://linux.die.net/man/5/acl is a good start.  This is our role model.

I'm gonna read that.

>   The new code will compute the mask the same way as before, but it
>   skips the permissions of SYSTEM and Administrators while doing that.
>   That means, the POSIX group permission bits are not affected by
>   the Windows-typical permissions of SYSTEM and Administrators.
> 
>   Example:
> 
>     User            rw-
>     Primary group   r--
>     Other user      rw-
>     Other group     r--
>     SYSTEM          rwx
>     Everyone        ---
> 
>   The computed POSIX MASK/CLASS_OBJ value in Cygwin 1.7.35 is the sum
>   of all group and secondary user permissions
> 
>     rw- | r-- | rwx == rwx
> 
>   The new code ignores SYSTEM, thus the mask is
> 
>     rw- | r-- == rw-
>      
> Does this explain it sufficiently?

Yes, thank you. My question was about the case where SYSTEM or Administrator doesn't have the typical permissions. From this explanation, I assume that I won't be able to see any difference in the mask in that case, but it doesn't seem to be a bad thing.

-- 
David Macek


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4234 bytes --]

Re: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 11 05:47, Steven Penny wrote:
> On Sat, Apr 11, 2015 at 4:40 AM, Corinna Vinschen wrote:
> > What is '~+'?  Is that some weird bash feature?
> 
> If the tilde-prefix is ‘~+’, the value of the shell variable PWD replaces the
> tilde-prefix.

Ah, thanks.  Learn something new each day (tcsh user here).


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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 11 14:35, David Macek wrote:
> On 11. 4. 2015 11:59, Corinna Vinschen wrote:
> >> Out of curiosity, does the code somehow distinguish ACLs that don't
> >> have these default permissions (or have different permissions set for
> >> SYSTEM / Administrators)?
> > 
> > I don't quite understand the question.
> > 
> > For a start, I'd like to point out how POSIX ACLs are supposed to work.
> > http://linux.die.net/man/5/acl is a good start.  This is our role model.
> 
> I'm gonna read that.
> 
> >   The new code will compute the mask the same way as before, but it
> >   skips the permissions of SYSTEM and Administrators while doing that.
> >   That means, the POSIX group permission bits are not affected by
> >   the Windows-typical permissions of SYSTEM and Administrators.
> > 
> >   Example:
> > 
> >     User            rw-
> >     Primary group   r--
> >     Other user      rw-
> >     Other group     r--
> >     SYSTEM          rwx
> >     Everyone        ---
> > 
> >   The computed POSIX MASK/CLASS_OBJ value in Cygwin 1.7.35 is the sum
> >   of all group and secondary user permissions
> > 
> >     rw- | r-- | rwx == rwx
> > 
> >   The new code ignores SYSTEM, thus the mask is
> > 
> >     rw- | r-- == rw-
> >      
> > Does this explain it sufficiently?
> 
> Yes, thank you. My question was about the case where SYSTEM or
> Administrator doesn't have the typical permissions. From this
> explanation, I assume that I won't be able to see any difference in
> the mask in that case, but it doesn't seem to be a bad thing.

I'm seriously hoping so.


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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 11 07:11, Bryan Berns wrote:
> >> >   That means, even if SYSTEM or Administrators have full access to the
> >> >   file, the POSIX permssion bits will not reflect that fact.  And while
> >> >   other users get access denied based on the mask value, SYSTEM and
> >> >   Administrators will never get access denied based on the mask.
> >>
> >> If you want to put this to better use in larger settings it would seem
> >> preferrable if it was possible to define a list of users to treat this
> >> way in fstab.
> >
> > Nope, sorry, no configuration for this.  Either it's handled without
> > any exception, or for SYSTEM only, or for SYSTEM+Admins.  But either
> > way, we're doing it the same way on every system.
> 
> Damn.  I was about to reply with Achim's exact same thought --- like a
> file in /etc with a list of SIDs.  I can empathize with Corinna's veto
> though -- having a hundred tweak-able settings in Cygwin is
> unmaintainable for the general populous.  I may apply a local patch to
> extend this ability myself because Cygwin has become rather unusable
> for users with home's on our network drives (given all the programs
> that attempt to do sanity checks on group perms).

I'd suggest to give the new ACL handling sa try first.  It might not
be as bad (anymore) as you think.

> That said, I appreciate what has been integrated --- it will help in
> several scenarios.  I will test the release this weekend.  Thanks for
> all the hard work!


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: [TESTERS needed] New POSIX permission handling

[Andrey Repin]

Greetings, Steven Penny!

>> What is '~+'?  Is that some weird bash feature?

> If the tilde-prefix is ‘~+’, the value of the shell variable PWD replaces the
> tilde-prefix.

> http://gnu.org/software/bash/manual/html_node/Tilde-Expansion

In other words, "~+/" is a weird way to say "./" ?


-- 
With best regards,
Andrey Repin
Saturday, April 11, 2015 18:57:50

Sorry for my terrible english...

Re: [TESTERS needed] New POSIX permission handling

[Andrey Repin]

Greetings, Achim Gratz!

> Corinna Vinschen writes:
>> - To accommodate Windows default ACLs, the new code ignores SYSTEM and
>>   Administrators group permissions when computing the MASK/CLASS_OBJ
>>   permission mask on old ACLs, and it doesn't deny access to SYSTEM and
>>   Administrators group based on the value of MASK/CLASS_OBJ when
>>   creating the new ACLs.

> Since you've now opened that can of worms of who is considered "root",
> what about "Domain Administrators" or "Power Users", for starters?

"Domain Admins" is a members of local "Administrators" group.
And "Power Users" are just users with a little more power, but not by much.


-- 
With best regards,
Andrey Repin
Saturday, April 11, 2015 18:58:52

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: [TESTERS needed] New POSIX permission handling

[Ernie Rael]

I'm primarily a lurker, reading this list hoping things soak in a bit. 
So I may be off base on this.

In the table below, describing "NULL DENY access mask", looks like 
there's a typo concerning read/execute. (of course it might just be a 
windows mapping peculiarity that I really didn't want to know about ;-)

-ernie

On 4/11/2015 3:07 AM, Corinna Vinschen wrote:
> On Apr 11 11:40, Corinna Vinschen wrote:
>> On Apr 10 19:00, Steven Penny wrote:
>>> On Fri, Apr 10, 2015 at 5:07 AM, Corinna Vinschen wrote:
>>>> Please give the new code a try.  I uploaded new 2015-04-10 developer
>>>> snapshots to https://cygwin.com/snapshots/
>>> Here is the test I ran:
>>>
>>>      $ cd /cygdrive/c
>>>
>>>      $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
>>>
>>>      $ chmod +x ~/bravo.sh ~+/delta.sh
>>>
>>>      $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
>>>      -rw-rw-r--+ 1 John None 0 Apr 10 16:51 /cygdrive/c/charlie.sh
>>>      -rwxrwxr-x+ 1 John None 0 Apr 10 16:51 /cygdrive/c/delta.sh    (green)
>>>      -rw-r--r--  1 John None 0 Apr 10 16:51 /home/John/alpha.sh
>>>      -rwxrwxr-x  1 John None 0 Apr 10 16:51 /home/John/bravo.sh     (green)
>>>
>>> So "charlie.sh" looks strange because it has that extra write permission.
>>> However this is not a big deal for me. My concern was that everything was
>>> showing up executable (green) when running "ls --color". So overall this is an
>>> improvement, thanks.
>> What is '~+'?  Is that some weird bash feature?
>>
>> Did you check the ACL?  The ACL before and after the change should
>> explain what happened.  Check it with getfacl *and* icacls to get
>> an idea what it looks like, and compare the result with the POSIX
>> ACL rules, as outlined on, e.g., http://linux.die.net/man/5/acl.
> On second thought, what you need to know is what the NULL DENY ACE looks
> like when looking at it in icacls.
>
> The following bits in the NULL DENY access mask are used:
>
>    Windows access    <->   POSIX access
>    --------------          ------------
>    FILE_READ_DATA          S_ISVTX
>    FILE_WRITE_DATA         S_ISGID
>    FILE_APPEND_DATA        S_ISUID
>
>    FILE_READ_EA            MASK S_IXOTH  (POSIX execute perms)
>    FILE_WRITE_EA           MASK S_IWOTH  (POSIX write perms)
>    FILE_EXECUTE            MASK S_IROTH  (POSIX read perms)

Are read and execute swapped intentionally in the above?

>
>    FILE_DELETE_CHILD       Set if MASK is valid
>
>    READ_CONTROL            Set to mark this as a "new style" ACL.
>
>    SYNCHRONIZE             Has no meaning, but icacls has a bug in
>                            printing the access mask of DENY ACEs.
>
> Same bits are used in the inheritable NULL DENY, but S_ISVTX and S_ISUID
> should never be set, because they are not supposed to be inherited,
>
>
> HTH,
> Corinna
>


--
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: [TESTERS needed] New POSIX permission handling

[donmez]

Hi,


Corinna Vinschen-2 wrote
> Hi folks,
> 
> 
> I just applied a patch I'm working on for quite some time now.  As I
> outlined before on this list, the POSIX permission handling has aged
> considerably and, for historical reasons, did things differently
> dependent on the calling function.  I took the time to reimplement the
> core functionality to handle all ACLs as strictly following POSIX ACL
> rules as possible.

I tested the updated package and at least quilt and mutt seems to broken by
the permission changes:

[~]> quilt new foo
cat: /tmp/quilt.mwTVWM: Permission denied
Patch patches/foo is now on top

And running mutt results in:

"Error creating temporary file /tmp/mutt-...."

Rolling back to an older snapshot fixes the problem.






--
View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117455.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 11 09:26, Ernie Rael wrote:
> I'm primarily a lurker, reading this list hoping things soak in a bit. So I
> may be off base on this.
> 
> In the table below, describing "NULL DENY access mask", looks like there's a
> typo concerning read/execute. (of course it might just be a windows mapping
> peculiarity that I really didn't want to know about ;-)

Hey, cool, somebody noticed :)
And since you asked, you'll get to know, whether you want or not ;)

> >The following bits in the NULL DENY access mask are used:
> >
> >   Windows access    <->   POSIX access
> >   --------------          ------------
> >   FILE_READ_DATA          S_ISVTX
> >   FILE_WRITE_DATA         S_ISGID
> >   FILE_APPEND_DATA        S_ISUID
> >
> >   FILE_READ_EA            MASK S_IXOTH  (POSIX execute perms)
> >   FILE_WRITE_EA           MASK S_IWOTH  (POSIX write perms)
> >   FILE_EXECUTE            MASK S_IROTH  (POSIX read perms)
> 
> Are read and execute swapped intentionally in the above?

Yes, indeed.  since the NULL access mask is not needed for actual
permission checking by Windows, we can use the bit as they fit our
needs.  The reason for using them in this order are their bit values.

  FILE_READ_EA  == 0x08       S_IXOTH == 0x01
  FILE_WRITE_EA == 0x10       S_IWOTH == 0x02
  FILE_EXECUTE  == 0x20       S_IROTH == 0x04

To convert from Windows to POSIX and vice versa, a simple shift
operation is sufficient.  Reordering just to fit the symbolic name
would complicate the conversion unnecessarily.


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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 11 10:11, donmez wrote:
> Hi,
> 
> 
> Corinna Vinschen-2 wrote
> > Hi folks,
> > 
> > 
> > I just applied a patch I'm working on for quite some time now.  As I
> > outlined before on this list, the POSIX permission handling has aged
> > considerably and, for historical reasons, did things differently
> > dependent on the calling function.  I took the time to reimplement the
> > core functionality to handle all ACLs as strictly following POSIX ACL
> > rules as possible.
> 
> I tested the updated package and at least quilt and mutt seems to broken by
> the permission changes:
> 
> [~]> quilt new foo
> cat: /tmp/quilt.mwTVWM: Permission denied
> Patch patches/foo is now on top
> 
> And running mutt results in:
> 
> "Error creating temporary file /tmp/mutt-...."
> 
> Rolling back to an older snapshot fixes the problem.

Thanks, but... 

No offense, but this is not overly helpful.  The problem is to learn
*why* this happens and how to fix it.  For that I'd need to know what
your permissions on /tmp look like (ls -l, getfacl, icacls).  Creating
files in my /tmp (having an old-style ACL) with the following
permissions works as desired for me:

  $ uname -rm
  2.0.0(0.287/5/3) x86_64
  $ ls -ld /tmp
  drwxrwxrwt+ 1 corinna vinschen 0 Apr 12 10:25 /tmp
  $ getfacl /tmp
  # file: /tmp
  # owner: corinna
  # group: vinschen
  # flags: --t
  user::rwx
  group::rwx
  mask:rwx
  other:rwx
  default:user::rwx
  default:group::r-x
  default:mask:r-x
  default:other:r-x

  $ icacls C:\\cygwin64\\tmp
  C:\cygwin64\tmp VINSCHEN\corinna:(F)
		  VINSCHEN\vinschen:(RX,W)
		  Everyone:(RX,W)
		  NULL SID:(RD)
		  CREATOR OWNER:(OI)(CI)(IO)(F)
		  CREATOR GROUP:(OI)(CI)(IO)(RX)
		  Everyone:(OI)(CI)(IO)(RX)

  Successfully processed 1 files; Failed processing 0 files
  $ touch /tmp/foo
  $ ls -l /tmp/foo
  -rw-r--r-- 1 corinna vinschen 0 Apr 12 10:25 /tmp/foo
  $ getfacl /tmp/foo
  # file: /tmp/foo
  # owner: corinna
  # group: vinschen
  user::rw-
  group::r-x
  mask:r--
  other:r--

  $ icacls C:\\cygwin64\\tmp\\foo
  C:\cygwin64\tmp\foo NULL SID:(DENY)(Rc,S,X,DC)
		      VINSCHEN\corinna:(R,W,D,WDAC,WO)
		      VINSCHEN\vinschen:(DENY)(S,X)
		      VINSCHEN\vinschen:(RX)
		      Everyone:(R)

  Successfully processed 1 files; Failed processing 0 files
  $


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: [TESTERS needed] New POSIX permission handling

[İsmail Dönmez]

Hi,


Corinna Vinschen-2 wrote
> On Apr 11 10:11, donmez wrote:
>> Hi,
>> 
>> 
>> Corinna Vinschen-2 wrote
>> > Hi folks,
>> > 
>> > 
>> > I just applied a patch I'm working on for quite some time now.  As I
>> > outlined before on this list, the POSIX permission handling has aged
>> > considerably and, for historical reasons, did things differently
>> > dependent on the calling function.  I took the time to reimplement the
>> > core functionality to handle all ACLs as strictly following POSIX ACL
>> > rules as possible.
>> 
>> I tested the updated package and at least quilt and mutt seems to broken
>> by
>> the permission changes:
>> 
>> [~]> quilt new foo
>> cat: /tmp/quilt.mwTVWM: Permission denied
>> Patch patches/foo is now on top
>> 
>> And running mutt results in:
>> 
>> "Error creating temporary file /tmp/mutt-...."
>> 
>> Rolling back to an older snapshot fixes the problem.
> 
> Thanks, but... 
> 
> No offense, but this is not overly helpful.  The problem is to learn
> *why* this happens and how to fix it.  For that I'd need to know what
> your permissions on /tmp look like (ls -l, getfacl, icacls).  Creating
> files in my /tmp (having an old-style ACL) with the following
> permissions works as desired for me:

Hopefully this will shed some more light:

[~]> uname -rm
2.0.0(0.287/5/3) x86_64

[~]> ls -ld /tmp
drwxrwxrwt+ 1 ismail ismail 0 Apr 12 16:13 /tmp

[~]> getfacl /tmp
# file: /tmp
# owner: ismail
# group: ismail
# flags: --t
user::rwx
user:ismail:rwx
group::rwx
mask:rwx
other:rwx
default:user::rwx
default:group::r-x
default:mask:r-x
default:other:r-x

[~]> icacls C:\\cygwin64\\tmp
C:\cygwin64\tmp UX31A\ismail:(F)
        UX31A\ismail:(RX,W)
        Everyone:(RX,W)
        NULL SID:(RD)
        CREATOR OWNER:(OI)(CI)(IO)(F)
        CREATOR GROUP:(OI)(CI)(IO)(RX)
        Everyone:(OI)(CI)(IO)(RX)

       Successfully processed 1 files; Failed processing 0 files

[~]> touch /tmp/foo

[~]> ls -l /tmp/foo
-rw-r--r--+ 1 ismail ismail 0 Apr 12 16:16 /tmp/foo

[~]> getfacl /tmp/foo
# file: /tmp/foo
# owner: ismail
# group: ismail
user::rw-
user:ismail:r-x
group::---
mask:r--
other:r--

[~]> icacls C:\\cygwin64\\tmp\\foo
C:\cygwin64\tmp\foo 
        NULL SID:(DENY)(Rc,S,X,DC)
        UX31A\ismail:(DENY)(S,X)
        UX31A\ismail:(R,W,D,WDAC,WO)
        UX31A\ismail:(RX)
        UX31A\ismail:(DENY)(S,X)
        UX31A\ismail:(RX)
        Everyone:(R)

Successfully processed 1 files; Failed processing 0 files

<brown paper bag> I hope this to be a generic bug, skimmed over one
important details. This is on Win 10 beta build 10049 x64</brown paper bag>.

Thanks!




--
View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117479.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 12 06:21, İsmail Dönmez wrote:
> Hi,
> 
> 
> Corinna Vinschen-2 wrote
> > On Apr 11 10:11, donmez wrote:
> >> Hi,
> >> 
> >> 
> >> Corinna Vinschen-2 wrote
> >> > Hi folks,
> >> > 
> >> > 
> >> > I just applied a patch I'm working on for quite some time now.  As I
> >> > outlined before on this list, the POSIX permission handling has aged
> >> > considerably and, for historical reasons, did things differently
> >> > dependent on the calling function.  I took the time to reimplement the
> >> > core functionality to handle all ACLs as strictly following POSIX ACL
> >> > rules as possible.
> >> 
> >> I tested the updated package and at least quilt and mutt seems to broken
> >> by
> >> the permission changes:
> >> 
> >> [~]> quilt new foo
> >> cat: /tmp/quilt.mwTVWM: Permission denied
> >> Patch patches/foo is now on top
> >> 
> >> And running mutt results in:
> >> 
> >> "Error creating temporary file /tmp/mutt-...."
> >> 
> >> Rolling back to an older snapshot fixes the problem.
> > 
> > Thanks, but... 
> > 
> > No offense, but this is not overly helpful.  The problem is to learn
> > *why* this happens and how to fix it.  For that I'd need to know what
> > your permissions on /tmp look like (ls -l, getfacl, icacls).  Creating
> > files in my /tmp (having an old-style ACL) with the following
> > permissions works as desired for me:
> 
> Hopefully this will shed some more light:

It does, thank you.  The problem is the dreaded "owner == group" problem
introduced with these weird Microsoft accounts.  I completely forgot
about this while implementing the new code.  It's pretty tricky to get
the Windows ACL right for this.  Additionally the ACLs already created
by setup are... borderline correct only.  Back to the drawing board...


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: [TESTERS needed] New POSIX permission handling

[Adam Dinwoodie]

On 11/04/2015 16:58, Andrey Repin wrote:
> Greetings, Steven Penny!
 >
 >>> What is '~+'?  Is that some weird bash feature?
 >
 >> If the tilde-prefix is ‘~+’, the value of the shell variable PWD
 >> replaces the tilde-prefix.
 >
 >> http://gnu.org/software/bash/manual/html_node/Tilde-Expansion
 >
 > In other words, "~+/" is a weird way to say "./" ?

Strictly, no: `echo ./` will print `./`, while `echo ~+/` will print the 
absolute current path, the same as `echo "$PWD"/` would.


--
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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

Hi Ismail,

On Apr 12 16:25, Corinna Vinschen wrote:
> On Apr 12 06:21, İsmail Dönmez wrote:
> > Corinna Vinschen-2 wrote
> > > On Apr 11 10:11, donmez wrote:
> > >> Corinna Vinschen-2 wrote
> > >> > I just applied a patch I'm working on for quite some time now.  As I
> > >> > outlined before on this list, the POSIX permission handling has aged
> > >> > considerably and, for historical reasons, did things differently
> > >> > dependent on the calling function.  I took the time to reimplement the
> > >> > core functionality to handle all ACLs as strictly following POSIX ACL
> > >> > rules as possible.
> > >> 
> > >> I tested the updated package and at least quilt and mutt seems to broken
> > >> by
> > >> the permission changes:
> > >> [...]
> > > No offense, but this is not overly helpful.  The problem is to learn
> > > *why* this happens and how to fix it.  For that I'd need to know what
> > > your permissions on /tmp look like (ls -l, getfacl, icacls).  Creating
> > > files in my /tmp (having an old-style ACL) with the following
> > > permissions works as desired for me:
> > 
> > Hopefully this will shed some more light:
> 
> It does, thank you.  The problem is the dreaded "owner == group" problem
> introduced with these weird Microsoft accounts.  I completely forgot
> about this while implementing the new code.  It's pretty tricky to get
> the Windows ACL right for this.  Additionally the ACLs already created
> by setup are... borderline correct only.  Back to the drawing board...

I just applied a patch which is supposed to handle this owner==group
scenario better.

In short, Cygwin will try to handle POSIX user and group permissions
separately, even if owner == group.  This is basically a fake as far
as the actual permissions of the account are concerned, but it allows
applications still to chmod to different user and group perms.  It
just *looks* different in the end.

The only restriction of this is that the POSIX user permissions are
always changed so that the user perms are >= the group perms in this
situation.  So this:

  chmod 460 foo

will be internally twisted into

  chmod 660 foo


I uploaded new developer snapshots to https://cygwin.com/snapshots/
and I'm just uploading a 2.0.0-0.5 test release with this change.

Please give either of them a try.  I'd be interested in feedback,
ideally with details if something doesn't work as desired.


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: [TESTERS needed] New POSIX permission handling

[Ismail Donmez]

Hi,


Corinna Vinschen-2 wrote
> Hi Ismail,
> 
> On Apr 12 16:25, Corinna Vinschen wrote:
>> On Apr 12 06:21, İsmail Dönmez wrote:
>> > Corinna Vinschen-2 wrote
>> > > On Apr 11 10:11, donmez wrote:
>> > >> Corinna Vinschen-2 wrote
>> > >> > I just applied a patch I'm working on for quite some time now.  As
>> I
>> > >> > outlined before on this list, the POSIX permission handling has
>> aged
>> > >> > considerably and, for historical reasons, did things differently
>> > >> > dependent on the calling function.  I took the time to reimplement
>> the
>> > >> > core functionality to handle all ACLs as strictly following POSIX
>> ACL
>> > >> > rules as possible.
>> > >> 
>> > >> I tested the updated package and at least quilt and mutt seems to
>> broken
>> > >> by
>> > >> the permission changes:
>> > >> [...]
>> > > No offense, but this is not overly helpful.  The problem is to learn
>> > > *why* this happens and how to fix it.  For that I'd need to know what
>> > > your permissions on /tmp look like (ls -l, getfacl, icacls). 
>> Creating
>> > > files in my /tmp (having an old-style ACL) with the following
>> > > permissions works as desired for me:
>> > 
>> > Hopefully this will shed some more light:
>> 
>> It does, thank you.  The problem is the dreaded "owner == group" problem
>> introduced with these weird Microsoft accounts.  I completely forgot
>> about this while implementing the new code.  It's pretty tricky to get
>> the Windows ACL right for this.  Additionally the ACLs already created
>> by setup are... borderline correct only.  Back to the drawing board...
> 
> I just applied a patch which is supposed to handle this owner==group
> scenario better.
> 
> In short, Cygwin will try to handle POSIX user and group permissions
> separately, even if owner == group.  This is basically a fake as far
> as the actual permissions of the account are concerned, but it allows
> applications still to chmod to different user and group perms.  It
> just *looks* different in the end.
> 
> The only restriction of this is that the POSIX user permissions are
> always changed so that the user perms are >= the group perms in this
> situation.  So this:
> 
>   chmod 460 foo
> 
> will be internally twisted into
> 
>   chmod 660 foo
> 
> 
> I uploaded new developer snapshots to https://cygwin.com/snapshots/
> and I'm just uploading a 2.0.0-0.5 test release with this change.

I tested the new test release (rm -rfd the cygwin installation and
re-installed from scratch just to be sure), my original testcase with quilt
and mutt works, BUT now when I run make install inside mutt source it
complains that /usr/bin/install cannot change permissions on the destination
executables.

Now this is a pretty vague error report but it might take some time before I
can post an easily reproducable error. Because running the same command
myself gives no error whatsoever. I'll try to come up with a better report.

Thanks a lot!




--
View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117615.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 16 03:20, Ismail Donmez wrote:
> Corinna Vinschen-2 wrote
> > I just applied a patch which is supposed to handle this owner==group
> > scenario better.
> > 
> > In short, Cygwin will try to handle POSIX user and group permissions
> > separately, even if owner == group.  This is basically a fake as far
> > as the actual permissions of the account are concerned, but it allows
> > applications still to chmod to different user and group perms.  It
> > just *looks* different in the end.
> > 
> > The only restriction of this is that the POSIX user permissions are
> > always changed so that the user perms are >= the group perms in this
> > situation.  So this:
> > 
> >   chmod 460 foo
> > 
> > will be internally twisted into
> > 
> >   chmod 660 foo
> > 
> > 
> > I uploaded new developer snapshots to https://cygwin.com/snapshots/
> > and I'm just uploading a 2.0.0-0.5 test release with this change.
> 
> I tested the new test release (rm -rfd the cygwin installation and
> re-installed from scratch just to be sure), my original testcase with quilt
> and mutt works, BUT now when I run make install inside mutt source it
> complains that /usr/bin/install cannot change permissions on the destination
> executables.

Hmm, ok.  Off the top of my head I don't understand this.

> can post an easily reproducable error. Because running the same command
> myself gives no error whatsoever. I'll try to come up with a better report.

That would be nice.  A good start would be to know what permission mask
install is trying to set the destination to.  Maybe that sheds some light.


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: [TESTERS needed] New POSIX permission handling

[Ismail Donmez]

Hi,


Corinna Vinschen-2 wrote
> On Apr 16 03:20, Ismail Donmez wrote:
>> Corinna Vinschen-2 wrote
>> > I just applied a patch which is supposed to handle this owner==group
>> > scenario better.
>> > 
>> > In short, Cygwin will try to handle POSIX user and group permissions
>> > separately, even if owner == group.  This is basically a fake as far
>> > as the actual permissions of the account are concerned, but it allows
>> > applications still to chmod to different user and group perms.  It
>> > just *looks* different in the end.
>> > 
>> > The only restriction of this is that the POSIX user permissions are
>> > always changed so that the user perms are >= the group perms in this
>> > situation.  So this:
>> > 
>> >   chmod 460 foo
>> > 
>> > will be internally twisted into
>> > 
>> >   chmod 660 foo
>> > 
>> > 
>> > I uploaded new developer snapshots to https://cygwin.com/snapshots/
>> > and I'm just uploading a 2.0.0-0.5 test release with this change.
>> 
>> I tested the new test release (rm -rfd the cygwin installation and
>> re-installed from scratch just to be sure), my original testcase with
>> quilt
>> and mutt works, BUT now when I run make install inside mutt source it
>> complains that /usr/bin/install cannot change permissions on the
>> destination
>> executables.
> 
> Hmm, ok.  Off the top of my head I don't understand this.
> 
>> can post an easily reproducable error. Because running the same command
>> myself gives no error whatsoever. I'll try to come up with a better
>> report.
> 
> That would be nice.  A good start would be to know what permission mask
> install is trying to set the destination to.  Maybe that sheds some light.

So I am trying to configure and install mutt, and the first error I see is
at the end of configure:

configure: creating ./config.status
chmod: changing permissions of './config.status': Permission denied
configure: error: write failure creating ./config.status

Well, looks like its right:

[~/src/mutt]> chmod +x config.status
chmod: changing permissions of ‘config.status’: Permission denied

[~/src/mutt]> uname -a
CYGWIN_NT-6.3 ux31a 2.0.0(0.287/5/3) 2015-04-15 17:39 x86_64 Cygwin

[~/src/mutt]> getfacl .
# file: .
# owner: ismail
# group: ismail
user::rwx
group::r-x
group:SYSTEM:rwx
group:Administrators:rwx
mask:r-x
other:r-x
default:user::rwx
default:group::r-x
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:mask:r-x
default:other:r-x

[~/src/mutt]> getfacl config.status
# file: config.status
# owner: ismail
# group: ismail
user::rwx
group::r-x
group:SYSTEM:rwx
group:Administrators:rwx
mask:r-x
other:r-x

Any ideas? :)

Thank you.




--
View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117621.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 16 09:09, Ismail Donmez wrote:
> Hi,
> 
> [...]
> So I am trying to configure and install mutt, and the first error I see is
> at the end of configure:
> 
> configure: creating ./config.status
> chmod: changing permissions of './config.status': Permission denied
> configure: error: write failure creating ./config.status
> 
> Well, looks like its right:
> 
> [~/src/mutt]> chmod +x config.status
> chmod: changing permissions of ‘config.status’: Permission denied
> 
> [~/src/mutt]> uname -a
> CYGWIN_NT-6.3 ux31a 2.0.0(0.287/5/3) 2015-04-15 17:39 x86_64 Cygwin
> 
> [~/src/mutt]> getfacl .
> # file: .
> # owner: ismail
> # group: ismail
> user::rwx
> group::r-x
> group:SYSTEM:rwx
> group:Administrators:rwx
> mask:r-x
> other:r-x
> default:user::rwx
> default:group::r-x
> default:group:SYSTEM:rwx
> default:group:Administrators:rwx
> default:mask:r-x
> default:other:r-x
> 
> [~/src/mutt]> getfacl config.status
> # file: config.status
> # owner: ismail
> # group: ismail
> user::rwx
> group::r-x
> group:SYSTEM:rwx
> group:Administrators:rwx
> mask:r-x
> other:r-x
> 
> Any ideas? :)

Not yet.  Can you add the output of icacls for both?  For easier
copy/pasting, just pipe the icacls output through `cat' for the time
being.


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: [TESTERS needed] New POSIX permission handling

[Ismail Donmez]

Corinna Vinschen-2 wrote
> On Apr 16 09:09, Ismail Donmez wrote:
>> Hi,
>> 
>> [...]
>> So I am trying to configure and install mutt, and the first error I see
>> is
>> at the end of configure:
>> 
>> configure: creating ./config.status
>> chmod: changing permissions of './config.status': Permission denied
>> configure: error: write failure creating ./config.status
>> 
>> Well, looks like its right:
>> 
>> [~/src/mutt]> chmod +x config.status
>> chmod: changing permissions of ‘config.status’: Permission denied
>> 
>> [~/src/mutt]> uname -a
>> CYGWIN_NT-6.3 ux31a 2.0.0(0.287/5/3) 2015-04-15 17:39 x86_64 Cygwin
>> 
>> [~/src/mutt]> getfacl .
>> # file: .
>> # owner: ismail
>> # group: ismail
>> user::rwx
>> group::r-x
>> group:SYSTEM:rwx
>> group:Administrators:rwx
>> mask:r-x
>> other:r-x
>> default:user::rwx
>> default:group::r-x
>> default:group:SYSTEM:rwx
>> default:group:Administrators:rwx
>> default:mask:r-x
>> default:other:r-x
>> 
>> [~/src/mutt]> getfacl config.status
>> # file: config.status
>> # owner: ismail
>> # group: ismail
>> user::rwx
>> group::r-x
>> group:SYSTEM:rwx
>> group:Administrators:rwx
>> mask:r-x
>> other:r-x
>> 
>> Any ideas? :)
> 
> Not yet.  Can you add the output of icacls for both?  For easier
> copy/pasting, just pipe the icacls output through `cat' for the time
> being.

[~/src/mutt]> icacls config.status
config.status NULL SID:(DENY)(Rc,S,REA,X,DC)
              UX31A\ismail:(F)
              UX31A\ismail:(RX)
              NT AUTHORITY\SYSTEM:(RX,W,DC)
              BUILTIN\Administrators:(RX,W,DC)
              Everyone:(RX)

Successfully processed 1 files; Failed processing 0 files

[~/src/mutt]> icacls .
. NULL SID:(DENY)(Rc,S,REA,X,DC)
  UX31A\ismail:(F)
  UX31A\ismail:(RX)
  NT AUTHORITY\SYSTEM:(RX,W,DC)
  BUILTIN\Administrators:(RX,W,DC)
  Everyone:(RX)
  NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,X,DC)
  CREATOR OWNER:(OI)(CI)(IO)(F)
  CREATOR GROUP:(OI)(CI)(IO)(RX)
  NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC)
  BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC)
  Everyone:(OI)(CI)(IO)(RX)

Successfully processed 1 files; Failed processing 0 files



--
View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117627.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

Hi Ismail,

On Apr 16 09:48, Ismail Donmez wrote:
> Corinna Vinschen-2 wrote
> > On Apr 16 09:09, Ismail Donmez wrote:
> >> [~/src/mutt]> chmod +x config.status
> >> chmod: changing permissions of ‘config.status’: Permission denied

This is really surprising.

> [~/src/mutt]> icacls config.status
> config.status NULL SID:(DENY)(Rc,S,REA,X,DC)
>               UX31A\ismail:(F)
>               UX31A\ismail:(RX)
>               NT AUTHORITY\SYSTEM:(RX,W,DC)
>               BUILTIN\Administrators:(RX,W,DC)
>               Everyone:(RX)
> 
> Successfully processed 1 files; Failed processing 0 files
> 
> [~/src/mutt]> icacls .
> . NULL SID:(DENY)(Rc,S,REA,X,DC)
>   UX31A\ismail:(F)
>   UX31A\ismail:(RX)
>   NT AUTHORITY\SYSTEM:(RX,W,DC)
>   BUILTIN\Administrators:(RX,W,DC)
>   Everyone:(RX)
>   NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,X,DC)
>   CREATOR OWNER:(OI)(CI)(IO)(F)
>   CREATOR GROUP:(OI)(CI)(IO)(RX)
>   NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC)
>   BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC)
>   Everyone:(OI)(CI)(IO)(RX)

I created the exact same scenario with the exact same ACLs, just with my
own account as user and group, and I can't reproduce a "Permission
denied".  chmod simply works for me.  Weird.

While looking into this I found some other problems in this owner==group
scenario, so I applied a few patches.  I'm just creating new developer
snapshots and a 2.0.0-0.6 test release.

It would be nice if you could update, test again, and if the problem
still occurs, I think I'll need an strace of the above chmod call as
in:

  $ strace -o chmod.trace chmod +x config.status

This combined with the icacls of the ACLs of config.status and the
parent dir, just to be sure the new Cygwin created the same ACLs.


Thanks in advance,
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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 17 09:30, Corinna Vinschen wrote:
> Hi Ismail,
> 
> On Apr 16 09:48, Ismail Donmez wrote:
> > Corinna Vinschen-2 wrote
> > > On Apr 16 09:09, Ismail Donmez wrote:
> > >> [~/src/mutt]> chmod +x config.status
> > >> chmod: changing permissions of ‘config.status’: Permission denied
> 
> This is really surprising.
> 
> > [~/src/mutt]> icacls config.status
> > config.status NULL SID:(DENY)(Rc,S,REA,X,DC)
> >               UX31A\ismail:(F)
> >               UX31A\ismail:(RX)
> >               NT AUTHORITY\SYSTEM:(RX,W,DC)
> >               BUILTIN\Administrators:(RX,W,DC)
> >               Everyone:(RX)
> > 
> > Successfully processed 1 files; Failed processing 0 files
> > 
> > [~/src/mutt]> icacls .
> > . NULL SID:(DENY)(Rc,S,REA,X,DC)
> >   UX31A\ismail:(F)
> >   UX31A\ismail:(RX)
> >   NT AUTHORITY\SYSTEM:(RX,W,DC)
> >   BUILTIN\Administrators:(RX,W,DC)
> >   Everyone:(RX)
> >   NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,X,DC)
> >   CREATOR OWNER:(OI)(CI)(IO)(F)
> >   CREATOR GROUP:(OI)(CI)(IO)(RX)
> >   NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC)
> >   BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC)
> >   Everyone:(OI)(CI)(IO)(RX)
> 
> I created the exact same scenario with the exact same ACLs, just with my
> own account as user and group, and I can't reproduce a "Permission
> denied".  chmod simply works for me.  Weird.
> 
> While looking into this I found some other problems in this owner==group
> scenario, so I applied a few patches.  I'm just creating new developer
> snapshots and a 2.0.0-0.6 test release.
> 
> It would be nice if you could update, test again, and if the problem
> still occurs, I think I'll need an strace of the above chmod call as
> in:
> 
>   $ strace -o chmod.trace chmod +x config.status
> 
> This combined with the icacls of the ACLs of config.status and the
> parent dir, just to be sure the new Cygwin created the same ACLs.

I think I found the culprit.  I'll uploade a -0.7 test release in
the next hour or so.


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

Re: [TESTERS needed] New POSIX permission handling

[Ismail Donmez]

Hi,


Corinna Vinschen-2 wrote
> On Apr 17 09:30, Corinna Vinschen wrote:
> I think I found the culprit.  I'll uploade a -0.7 test release in
> the next hour or so.

So far all my tests work, thanks a bunch!




--
View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117666.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
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: [TESTERS needed] New POSIX permission handling

[Corinna Vinschen]

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

On Apr 17 08:17, Ismail Donmez wrote:
> Hi,
> 
> 
> Corinna Vinschen-2 wrote
> > On Apr 17 09:30, Corinna Vinschen wrote:
> > I think I found the culprit.  I'll uploade a -0.7 test release in
> > the next hour or so.
> 
> So far all my tests work, thanks a bunch!

Thanks for your feedback!


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: [TESTERS needed] New POSIX permission handling

[Steven Penny]

On Fri, Apr 10, 2015 at 7:00 PM, Steven Penny wrote:
> Here is the test I ran:

The test I ran here
http://cygwin.com/ml/cygwin/2015-04/msg00186.html
is now failing again:

    $ cd /cygdrive/c

    $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh

    $ chmod +x ~/bravo.sh ~+/delta.sh

    $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
    -rw-rwxr--+ 1 John None 0 May 15 19:12 /cygdrive/c/charlie.sh  (green)
    -rwxrwxr-x+ 1 John None 0 May 15 19:12 /cygdrive/c/delta.sh    (green)
    -rw-r--r--  1 John None 0 May 15 19:12 /home/John/alpha.sh
    -rwxr-xr-x  1 John None 0 May 15 19:12 /home/John/bravo.sh     (green)

Please sort this out. Having ‘ls --color’ is pointless if everything is the same
color.

--
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: [TESTERS needed] New POSIX permission handling

[Duncan Roe]

On Fri, May 15, 2015 at 09:20:10PM -0500, Steven Penny wrote:
> On Fri, Apr 10, 2015 at 7:00 PM, Steven Penny wrote:
> > Here is the test I ran:
>
> The test I ran here
> http://cygwin.com/ml/cygwin/2015-04/msg00186.html
> is now failing again:
>
>     $ cd /cygdrive/c
>
>     $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
>
>     $ chmod +x ~/bravo.sh ~+/delta.sh
>
>     $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
>     -rw-rwxr--+ 1 John None 0 May 15 19:12 /cygdrive/c/charlie.sh  (green)
>     -rwxrwxr-x+ 1 John None 0 May 15 19:12 /cygdrive/c/delta.sh    (green)
>     -rw-r--r--  1 John None 0 May 15 19:12 /home/John/alpha.sh
>     -rwxr-xr-x  1 John None 0 May 15 19:12 /home/John/bravo.sh     (green)
>
> Please sort this out. Having ???ls --color??? is pointless if everything is the same
> color.
>
Your results look fine to me. In your original test, charlie.sh was -rw-rw-r--+,
but now it is -rw-rwxr--+ (i.e. it has acquired group execute access). So why
would you not expect it to show in green?

Cheers ... Duncan.

--
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: [TESTERS needed] New POSIX permission handling

[Jiří Engelthaler]

Here https://www.cygwin.com/ml/cygwin/2015-05/msg00139.html is another
posix permission related problem. Without answer from authors.

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