[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Corinna Vinschen]

Hi Cygwin friends and users,


New 2.0.0-0.7 test release:

- Improved setfacl tool.  It now handles mask recomputation just like
  the Linux tool.  -d option renamed to -x (but -d is still accepted
  for backward compat).  New -n,--no-mask and --mask options.

- Improved getfacl tool.  It now prints effective permissions just like
  the Linux tool.  --noname optioned renamed to --numeric (but --noname
  is still accepted for backward compat).  New -c,--omit-header,
  -e,--all-effective, and -E,--no-effective options.

- Fix a bug in account handling.  In certain scenarios a PSID pointer
  was pointing into a buffer space which got moved away due to a call to
  realloc.  This bug seems to be the problem of the reported "Permission
  denied" problems when trying to chmod.
  
- Add a missing check for uid/gid values which can't be resolved to
  Windows accounts.  chmod now returns EINVAL now in this case, just as
  the pre 2.0 DLLs.

- I introduced a change in chmod behaviour which is not exactly in
  line with POSIX 1003.1e draft 17:
  
  If you have a non-trivial ACL with secondary accounts and thus a mask
  value, chmod is supposed to change only the mask, not the permissions
  of the primary group.  However, if the primary group has few permissions
  to begin with, the result is really surprising.  ls -l would, e.g.,
  show read/write perms for the group, but the group might still have
  only read perms.

  Personally I find this chmod behaviour really, really bad, so I took
  the liberty to change it in a way which gives a much less surprising
  result:  If you call chmod on a non-trivial ACL, the group permissions
  will be used for the primary group and the mask.  I hope that this
  is working out ok.

- Fix a bug when reading DENAY ACEs of accounts with multiple entries
  (typically in the owner == group case).

- Fix how group perms are merged into owner perms in owner == group case.

- Fix a bug in SID handling which may result in broken SID info in
  passwd/group entries of unknown accounts.


Other than that...

The important change in this release is the POSIX permission handling
change, a rewrite of the underlying routines reading and creating
Windows ACLs following POSIX permission rules and POSIX ACL creating
rules per POSIX 1003.1e draft 17, as on Linux.

For a description of POSIX ACLs, see http://linux.die.net/man/5/acl


All changes in this release so far:
===================================

- New, unified implementation of POSIX permission and ACL handling.  The
  new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and
  they allow to inherit the S_ISGID bit.  ACL inheritance now really
  works as desired, in a limited, but theoretically equivalent fashion
  even for non-Cygwin processes.

  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.
  
  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.  This only works for files and directories
  created by Cygwin processes.
  
- basename(3) now comes in two flavors, POSIX and GNU.  The POSIX version is
  the default.  You get the GNU version after
  
    #define _GNU_SOURCE
    #include <string.h> 

- The maximum number of PTYs has been raised from 64 to 128.


Bug Fixes
---------
  
- Fix potential hang in pseudo ttys when generating ECHO output while the slave
  is flooding the pty with output.
  Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00019.html
  
- Fix potential premature SIGHUP in pty code.
  Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00070.html
  
- Fix a name change from symlink to target name in calls to execvp, system, etc.
  Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00270.html
      
- Fix internal error in pty -ONLCR handling.  Fix timing bug in pty OPOST 
  handling.
  Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00929.html

  NOTE: This change introduces a not yet addressed regression.
  Native Windows tools generating output with Unix LF instead of
  Windows CRLF line endings will not get OPOST handling.  This
  prominently affects icacls.

- Avoid creating passwd and group records from fully qualified Windows
  account names (domain\name, name@domain).
  Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00528.html

- Avoid potential crash at startup or in getgroups(2).
  Addresses: https://cygwin.com/ml/cygwin/2015-04/msg00010.html

- Fix UTF-16 surrogate handling in wctomb and friends.
  Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00452.html


To install 32-bit Cygwin use https://cygwin.com/setup-x86.exe
To install 64 bit Cygwin use https://cygwin.com/setup-x86_64.exe

If you're already running a 32 bit version of Cygwin on 64 bit Windows
machines, you can continue to do so.  If you're planning a new install
of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit
Cygwin version, unless you need certain packages not yet available in
the 64 bit release.


Have fun,
Corinna

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

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Achim Gratz]

Corinna Vinschen writes:
> New 2.0.0-0.7 test release:
>
> - Improved setfacl tool.  It now handles mask recomputation just like
>   the Linux tool.  -d option renamed to -x (but -d is still accepted
>   for backward compat).  New -n,--no-mask and --mask options.

"setfacl -b -k" still errors out instead of removing both the default
and extended ACL entries.

> The important change in this release is the POSIX permission handling
> change, a rewrite of the underlying routines reading and creating
> Windows ACLs following POSIX permission rules and POSIX ACL creating
> rules per POSIX 1003.1e draft 17, as on Linux.

I seem to have found another fly in that ointment (or rather cygport
did find it for me…):

While packaging a "find usr/ -type f -executable" would find newly
created info files that ls and getfacl agree are not executable:

-rw-------+ 1 ASSI Kein 48880  5. Apr 2014  ucl.log
# file: ucl.log
# owner: ASSI
# group: Kein
user::rw-
group::---
group:SYSTEM:rwx                        #effective:---
group:Administratoren:rwx               #effective:---
mask:---
other:---

It seems that some of the code doesn't take the masking bits into
account just yet.  Here's the relevant portion of an strace on a
different file (I had already deleted the ACL on the original ones):

  215   43687 [main] find 2808 normalize_posix_path: src /mnt/share/maint/ucl.log
   23   43710 [main] find 2808 normalize_posix_path: /mnt/share/maint/ucl.log = normalize_posix_path (/mnt/share/maint/ucl.log)
   35   43745 [main] find 2808 mount_info::conv_to_win32_path: conv_to_win32_path (/mnt/share/maint/ucl.log)
   28   43773 [main] find 2808 set_flags: flags: binary (0x2)
   27   43800 [main] find 2808 mount_info::conv_to_win32_path: src_path /mnt/share/maint/ucl.log, dst D:\Freeware\CygShare\maint\ucl.log, flags 0x2, rc 0
   63   43863 [main] find 2808 symlink_info::check: 0x0 = NtCreateFile (\??\D:\Freeware\CygShare\maint\ucl.log)
   43   43906 [main] find 2808 symlink_info::check: not a symlink
   57   43963 [main] find 2808 symlink_info::check: 0 = symlink.check(D:\Freeware\CygShare\maint\ucl.log, 0x23B600) (0x400002)
   24   43987 [main] find 2808 path_conv::check: this->path(D:\Freeware\CygShare\maint\ucl.log), has_acls(1)
   32   44019 [main] find 2808 build_fh_pc: fh 0x1802FEE38, dev 000000C3
   22   44041 [main] find 2808 stat_worker: (\??\D:\Freeware\CygShare\maint\ucl.log, 0x60003B6E0, 0x1802FEE38), file_attributes 32
  125   44166 [main] find 2808 fhandler_base::fstat_helper: 0 = fstat (\??\D:\Freeware\CygShare\maint\ucl.log, 0x60003B6E0) st_size=48880, st_mode=0100600, st_ino=281474977000743st_atim=533FAD65.25D44958 st_ctim=5531679B.D5E5E90 st_mtim=533FADD7.6CDF1E4 st_birthtim=533FAD65.25D44958
   27   44193 [main] find 2808 stat_worker: 0 = (\??\D:\Freeware\CygShare\maint\ucl.log,0x60003B6E0)
  226   44419 [main] find 2808 normalize_posix_path: src /mnt/share/maint/ucl.log
   23   44442 [main] find 2808 normalize_posix_path: /mnt/share/maint/ucl.log = normalize_posix_path (/mnt/share/maint/ucl.log)
   21   44463 [main] find 2808 mount_info::conv_to_win32_path: conv_to_win32_path (/mnt/share/maint/ucl.log)
   25   44488 [main] find 2808 set_flags: flags: binary (0x2)
   19   44507 [main] find 2808 mount_info::conv_to_win32_path: src_path /mnt/share/maint/ucl.log, dst D:\Freeware\CygShare\maint\ucl.log, flags 0x2, rc 0
   86   44593 [main] find 2808 symlink_info::check: 0x0 = NtCreateFile (\??\D:\Freeware\CygShare\maint\ucl.log)
   34   44627 [main] find 2808 symlink_info::check: not a symlink
   21   44648 [main] find 2808 symlink_info::check: 0 = symlink.check(D:\Freeware\CygShare\maint\ucl.log, 0x23B530) (0x400002)
   21   44669 [main] find 2808 path_conv::check: this->path(D:\Freeware\CygShare\maint\ucl.log), has_acls(1)
   38   44707 [main] find 2808 build_fh_pc: fh 0x1802FEE38, dev 000000C3
  110   44817 [main] find 2808 check_file_access: flags 0x1, ret 0
   47   44864 [main] find 2808 fhandler_base::fhaccess: returning 0
   44   44908 [main] find 2808 faccessat: returning 0

With the ACL removed, the trace looks like this instead:

 277   46985 [main] find 3992 normalize_posix_path: src /mnt/share/maint/ucl.log
   29   47014 [main] find 3992 normalize_posix_path: /mnt/share/maint/ucl.log = normalize_posix_path (/mnt/share/maint/ucl.log)
   39   47053 [main] find 3992 mount_info::conv_to_win32_path: conv_to_win32_path (/mnt/share/maint/ucl.log)
   20   47073 [main] find 3992 set_flags: flags: binary (0x2)
   18   47091 [main] find 3992 mount_info::conv_to_win32_path: src_path /mnt/share/maint/ucl.log, dst D:\Freeware\CygShare\maint\ucl.log, flags 0x2, rc 0
   58   47149 [main] find 3992 symlink_info::check: 0x0 = NtCreateFile (\??\D:\Freeware\CygShare\maint\ucl.log)
   51   47200 [main] find 3992 symlink_info::check: not a symlink
   20   47220 [main] find 3992 symlink_info::check: 0 = symlink.check(D:\Freeware\CygShare\maint\ucl.log, 0x23B600) (0x400002)
   23   47243 [main] find 3992 path_conv::check: this->path(D:\Freeware\CygShare\maint\ucl.log), has_acls(1)
   39   47282 [main] find 3992 build_fh_pc: fh 0x1802FEE38, dev 000000C3
   22   47304 [main] find 3992 stat_worker: (\??\D:\Freeware\CygShare\maint\ucl.log, 0x60003B6E0, 0x1802FEE38), file_attributes 32
  143   47447 [main] find 3992 fhandler_base::fstat_helper: 0 = fstat (\??\D:\Freeware\CygShare\maint\ucl.log, 0x60003B6E0) st_size=48880, st_mode=0100600, st_ino=281474977000743st_atim=533FAD65.25D44958 st_ctim=5531680B.36B1E654 st_mtim=533FADD7.6CDF1E4 st_birthtim=533FAD65.25D44958
   27   47474 [main] find 3992 stat_worker: 0 = (\??\D:\Freeware\CygShare\maint\ucl.log,0x60003B6E0)
  206   47680 [main] find 3992 normalize_posix_path: src /mnt/share/maint/ucl.log
   27   47707 [main] find 3992 normalize_posix_path: /mnt/share/maint/ucl.log = normalize_posix_path (/mnt/share/maint/ucl.log)
   18   47725 [main] find 3992 mount_info::conv_to_win32_path: conv_to_win32_path (/mnt/share/maint/ucl.log)
   68   47793 [main] find 3992 set_flags: flags: binary (0x2)
   24   47817 [main] find 3992 mount_info::conv_to_win32_path: src_path /mnt/share/maint/ucl.log, dst D:\Freeware\CygShare\maint\ucl.log, flags 0x2, rc 0
   51   47868 [main] find 3992 symlink_info::check: 0x0 = NtCreateFile (\??\D:\Freeware\CygShare\maint\ucl.log)
   42   47910 [main] find 3992 symlink_info::check: not a symlink
   21   47931 [main] find 3992 symlink_info::check: 0 = symlink.check(D:\Freeware\CygShare\maint\ucl.log, 0x23B530) (0x400002)
   65   47996 [main] find 3992 path_conv::check: this->path(D:\Freeware\CygShare\maint\ucl.log), has_acls(1)
   26   48022 [main] find 3992 build_fh_pc: fh 0x1802FEE38, dev 000000C3
   71   48093 [main] find 3992 __set_errno: int check_access(security_descriptor&, GENERIC_MAPPING&, ACCESS_MASK, int, bool):588 setting errno 13
   31   48124 [main] find 3992 check_file_access: flags 0x1, ret -1
   73   48197 [main] find 3992 fhandler_base::fhaccess: returning -1
   69   48266 [main] find 3992 faccessat: returning -1


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

SD adaptation for Waldorf rackAttack V1.04R1:
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Corinna Vinschen]

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

Hi Achim,

On Apr 17 22:09, Achim Gratz wrote:
> Corinna Vinschen writes:
> > New 2.0.0-0.7 test release:
> >
> > - Improved setfacl tool.  It now handles mask recomputation just like
> >   the Linux tool.  -d option renamed to -x (but -d is still accepted
> >   for backward compat).  New -n,--no-mask and --mask options.
> 
> "setfacl -b -k" still errors out instead of removing both the default
> and extended ACL entries.

I didn't work on that, but patches are welcome.

> > The important change in this release is the POSIX permission handling
> > change, a rewrite of the underlying routines reading and creating
> > Windows ACLs following POSIX permission rules and POSIX ACL creating
> > rules per POSIX 1003.1e draft 17, as on Linux.
> 
> I seem to have found another fly in that ointment (or rather cygport
> did find it for me…):
> 
> While packaging a "find usr/ -type f -executable" would find newly
> created info files that ls and getfacl agree are not executable:
> 
> -rw-------+ 1 ASSI Kein 48880  5. Apr 2014  ucl.log
> # file: ucl.log
> # owner: ASSI
> # group: Kein
> user::rw-
> group::---
> group:SYSTEM:rwx                        #effective:---
> group:Administratoren:rwx               #effective:---
> mask:---
> other:---
> 
> It seems that some of the code doesn't take the masking bits into
> account just yet.  Here's the relevant portion of an strace on a
> different file (I had already deleted the ACL on the original ones):

What means "deleting the ACL"?  You always have an ACL in some way, no?
What does getfacl and icacls print after the delete?

In theory, the access(2)/faccessat(2) functions should not rely at all
on the new code.  The reason is that they are implemented using the
underlying OS function to evaluate ACLs.  That means, they provide the
actual access the OS grants.

In the above case, SYSTEM and Administrators both have execute
permissions, because they are never masked if they are secondary
accounts, as outlined in the test release announcement.

So the result of access is the real thing, while the above output from
getfacl is wrong.  My bad.  It should never print an "effective" value
for SYSTEM and Administrators, but I forgot to handle them explicitely.
I'll fix that.


Corina

-- 
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Achim Gratz]

Corinna Vinschen writes:
>> -rw-------+ 1 ASSI Kein 48880  5. Apr 2014  ucl.log
>> # file: ucl.log
>> # owner: ASSI
>> # group: Kein
>> user::rw-
>> group::---
>> group:SYSTEM:rwx                        #effective:---
>> group:Administratoren:rwx               #effective:---
>> mask:---
>> other:---
>> 
>> It seems that some of the code doesn't take the masking bits into
>> account just yet.  Here's the relevant portion of an strace on a
>> different file (I had already deleted the ACL on the original ones):
>
> What means "deleting the ACL"?  You always have an ACL in some way, no?
> What does getfacl and icacls print after the delete?

It means "setfacl -b" in this case.  Which removes the (inherited) ACL
for SYSTEM and Administrators.

> In theory, the access(2)/faccessat(2) functions should not rely at all
> on the new code.  The reason is that they are implemented using the
> underlying OS function to evaluate ACLs.  That means, they provide the
> actual access the OS grants.

That means they do not lie to the user like the mode bits do.  Which
breaks all sorts of assumptions that POSIX programs are allowed to make.
In turn one will almost universally have to remove the corresponding ACL
grants (the inherited ACL will always have rwx modes) when using an
administrator account (in this particular instance that's an easy thing
to do, luckily).  This kind of brings us back to where we started with
the discussion of whether to handle SYSTEM and Administrators specially,
only that the point of decision is now moved from mode check to
(f)access(at).  The outcome is the same: if you can't remove those ACL,
then correct POSIX semantics aren't possible.

> In the above case, SYSTEM and Administrators both have execute
> permissions, because they are never masked if they are secondary
> accounts, as outlined in the test release announcement.

A POSIX program trying to shortcut the ACL handling would conclude it
doesn't need to look beyond the mode bits.  A program that checks with
faccessat anyway gets told a different story.  The only analogue to this
is with root having implicit access to files on UN*X systems, but I
think "executable" would still be determined from the mode bits in this
case.

> So the result of access is the real thing, while the above output from
> getfacl is wrong.  My bad.  It should never print an "effective" value
> for SYSTEM and Administrators, but I forgot to handle them explicitely.
> I'll fix that.

Thanks.


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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Corinna Vinschen]

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

On Apr 18 11:47, Achim Gratz wrote:
> Corinna Vinschen writes:
> > In theory, the access(2)/faccessat(2) functions should not rely at all
> > on the new code.  The reason is that they are implemented using the
> > underlying OS function to evaluate ACLs.  That means, they provide the
> > actual access the OS grants.
> 
> That means they do not lie to the user like the mode bits do.  Which
> breaks all sorts of assumptions that POSIX programs are allowed to make.
> In turn one will almost universally have to remove the corresponding ACL
> grants (the inherited ACL will always have rwx modes) when using an
> administrator account (in this particular instance that's an easy thing
> to do, luckily).  This kind of brings us back to where we started with
> the discussion of whether to handle SYSTEM and Administrators specially,
> only that the point of decision is now moved from mode check to
> (f)access(at).  The outcome is the same: if you can't remove those ACL,
> then correct POSIX semantics aren't possible.

Right.  It's a compromise.  I take it you don't like the extra behaviour
for SYSTEM/Admins.  Neither do I.  Others are desperately waiting for
more.  The problem with compromises is, they are usually best if nobody
is completely satisfied ;)

As I said before, this behaviour is not necessarily the last word.
We have to see how this works out.  The point you're making here
is certainly a point against this implementation.  But I'm willing
to defend it to get more testing.

> > In the above case, SYSTEM and Administrators both have execute
> > permissions, because they are never masked if they are secondary
> > accounts, as outlined in the test release announcement.
> 
> A POSIX program trying to shortcut the ACL handling would conclude it
> doesn't need to look beyond the mode bits.  A program that checks with
> faccessat anyway gets told a different story.  The only analogue to this
> is with root having implicit access to files on UN*X systems, but I
> think "executable" would still be determined from the mode bits in this
> case.

Uh, not quite.  POSIX defines

   If any access permissions are checked, each shall be checked
   individually, as described in XBD File Access Permissions , except
   that where that description refers to execute permission for a
   process with appropriate privileges, an implementation may indicate
   success for X_OK even if execute permission is not granted to any
   user.


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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Achim Gratz]

Corinna Vinschen writes:
> Right.  It's a compromise.  I take it you don't like the extra behaviour
> for SYSTEM/Admins.  Neither do I.  Others are desperately waiting for
> more.  The problem with compromises is, they are usually best if nobody
> is completely satisfied ;)

I have argued against treating them differently, purely based on
consistency between the Windows and POSIX world (where possible at all).
Other considerations have prevailed (maybe rightly so), so I'm not too
surprised to find some inconsistency in the results.

> As I said before, this behaviour is not necessarily the last word.
> We have to see how this works out.  The point you're making here
> is certainly a point against this implementation.  But I'm willing
> to defend it to get more testing.

It probably works out OK for non-administrative users and prevents the
need for them to deal with Windows defaults they can't change anyway, so
that's a positive.  The problems when working with administrative rights
have just shifted to a slightly different place, but it seems you still
have to employ the same workarounds.

>> > In the above case, SYSTEM and Administrators both have execute
>> > permissions, because they are never masked if they are secondary
>> > accounts, as outlined in the test release announcement.
>> 
>> A POSIX program trying to shortcut the ACL handling would conclude it
>> doesn't need to look beyond the mode bits.  A program that checks with
>> faccessat anyway gets told a different story.  The only analogue to this
>> is with root having implicit access to files on UN*X systems, but I
>> think "executable" would still be determined from the mode bits in this
>> case.
>
> Uh, not quite.  POSIX defines
>
>    If any access permissions are checked, each shall be checked
>    individually, as described in XBD File Access Permissions , except
>    that where that description refers to execute permission for a
>    process with appropriate privileges, an implementation may indicate
>    success for X_OK even if execute permission is not granted to any
>    user.

I don't think you'll find a UN*X system that reports executable
permission on a plain file simply because root accesses it (for a
directory it would do that of course).  The situation in the above case
is on the face of it different (the ACL actually has the executable bit
set), but as I understand you've been wanting to treat both secondaries
like the root account.  I think it would be more sensible to ignore that
execute permission on plain files when otherwise none is granted (since
chmod will never mask it).  That would eliminate another reason to
entirely remove the default/inherited ACL and I don't think it has any
consequences on the Windows side.


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

SD adaptation for Waldorf rackAttack V1.04R1:
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Corinna Vinschen]

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

On Apr 18 12:48, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Right.  It's a compromise.  I take it you don't like the extra behaviour
> > for SYSTEM/Admins.  Neither do I.  Others are desperately waiting for
> > more.  The problem with compromises is, they are usually best if nobody
> > is completely satisfied ;)
> 
> I have argued against treating them differently, purely based on
> consistency between the Windows and POSIX world (where possible at all).
> Other considerations have prevailed (maybe rightly so), so I'm not too
> surprised to find some inconsistency in the results.

Neither am I.  We're walking a fine line between two very different
systems handling ACLs.

> I don't think you'll find a UN*X system that reports executable
> permission on a plain file simply because root accesses it (for a
> directory it would do that of course).  The situation in the above case
> is on the face of it different (the ACL actually has the executable bit
> set), but as I understand you've been wanting to treat both secondaries
> like the root account.  I think it would be more sensible to ignore that
> execute permission on plain files when otherwise none is granted (since
> chmod will never mask it).  That would eliminate another reason to
> entirely remove the default/inherited ACL and I don't think it has any
> consequences on the Windows side.

Hang on.  As far as access(2) is concerned, Cygwin can't ignore the
execute permssions since the OS has its say here.  I don't think it's
overly helpful to tweak the result after the OS returned it, dependent
on the user being SYSTEM or having the Admins group in the token.
That's a lot of extra work for a questionable gain.

What we *could* try to do is to tweak the actual SYSTEM and Admins ACE,
though.  Rather than ignoring the CLASS_OBJ/ACL_MASK value completely
for them, we could apply the execute bit part only.  Usually it doesn't
make sense for SYSTEM/Admins having execute perms if nobody else has
since it's with high probability no executable file.

Would that make sense?


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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Achim Gratz]

Corinna Vinschen writes:
> What we *could* try to do is to tweak the actual SYSTEM and Admins ACE,
> though.  Rather than ignoring the CLASS_OBJ/ACL_MASK value completely
> for them, we could apply the execute bit part only.  Usually it doesn't
> make sense for SYSTEM/Admins having execute perms if nobody else has
> since it's with high probability no executable file.

I think that would resolve this particular problem and leaves the
inherited part of the ACL as is.

> Would that make sense?

To me, yes.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> New 2.0.0-0.7 test release:

It looks like I found a bug or at least some extremely undesirable
behaviour.  We back up some data via rsync, the script doesn't use the --acl
option yet (that will need to change).  The bug happens without this option,
so rsync tries to preserve the modes, which ends up making the files
inaccessible.  The file share we back up from have ACL to grant the access
only to certain groups and disallow to change the DACL.  In trying to get
the modes set up in the same way, Cygwin rsync produces some DENY ACL that
will completely lock me out (the windows GUI will not only complain about
the order of ACL, it will also not show all ACL, so icacls is the only tool
that can be used from that point forward).  I'm not really sure what rsync
is doing here... it may need to become smarter about that possibility.

(1020)...Backup_rsync/~2015-04-20_15~37 > `cygpath -S`/icacls ..
.. BUILTIN\Administrators:(I)(F)
   BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
   NT AUTHORITY\SYSTEM:(I)(F)
   NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
   NT AUTHORITY\Authenticated Users:(I)(M)
   NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
   BUILTIN\Users:(I)(RX)
   BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
   Everyone:(I)(OI)(IO)(M,GA)
   Everyone:(I)(CI)(F)

1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler
aufgetreten.
(1021)...Backup_rsync/~2015-04-20_15~37 > `cygpath -S`/icacls .
. NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
  DOM\gratz:(F)
  BUILTIN\Users:(DENY)(W,DC)
  DOM\Domain Users:(RX,W,DC)
  NT AUTHORITY\Authenticated Users:(RX,W,DC)
  NT AUTHORITY\SYSTEM:(RX,W,DC)
  BUILTIN\Administrators:(RX,W,DC)
  BUILTIN\Users:(RX)
  Everyone:(RX,W,DC)
  NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,WEA,X,DC)
  CREATOR OWNER:(OI)(CI)(IO)(F)
  CREATOR GROUP:(OI)(CI)(IO)(DENY)(W,DC)
  BUILTIN\Users:(OI)(CI)(IO)(DENY)(W,DC)
  CREATOR GROUP:(OI)(CI)(IO)(RX)
  NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(RX,W,DC)
  NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC)
  BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC)
  BUILTIN\Users:(OI)(CI)(IO)(RX)
  Everyone:(OI)(CI)(IO)(RX,W,DC)

1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler
aufgetreten.
(1022)...Backup_rsync/~2015-04-20_15~37 > `cygpath -S`/icacls \*
dir1 NULL SID:(DENY)(Rc,S,DC)
     NT AUTHORITY\Authenticated Users:(DENY)(W,RD,REA,X,DC)
     BUILTIN\Users:(DENY)(S,RD,REA,X)
     NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,WEA,X,DC)
     CREATOR GROUP:(OI)(CI)(IO)(DENY)(W,DC)
     BUILTIN\Users:(OI)(CI)(IO)(DENY)(W,DC)
     DOM\gratz:(D,Rc,WDAC,WO,RA,WA)
     DOM\Domain Users:(Rc,S,RA)
     NT AUTHORITY\Authenticated Users:(RX,W,DC)
     NT AUTHORITY\SYSTEM:(RX,W,DC)
     BUILTIN\Administrators:(RX,W,DC)
     BUILTIN\Users:(RX)
     Everyone:(Rc,S,RA)
     CREATOR OWNER:(OI)(CI)(IO)(F)
     CREATOR GROUP:(OI)(CI)(IO)(RX)
     NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(RX,W,DC)
     NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC)
     BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC)
     BUILTIN\Users:(OI)(CI)(IO)(RX)
     Everyone:(OI)(CI)(IO)(RX,W,DC)
     DOM\gratz:(OI)(CI)(F)

dir2 NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
     DOM\gratz:(DENY)(S,RD,WD,AD,REA,WEA,X,DC)
     NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,WEA,X,DC)
     CREATOR GROUP:(OI)(CI)(IO)(DENY)(W,DC)
     BUILTIN\Users:(OI)(CI)(IO)(DENY)(W,DC)
     DOM\gratz:(D,Rc,WDAC,WO,RA,WA)
     DOM\Domain Users:(RX,W,DC)
     NT AUTHORITY\Authenticated Users:(RX,W,DC)
     NT AUTHORITY\SYSTEM:(RX,W,DC)
     BUILTIN\Administrators:(RX,W,DC)
     BUILTIN\Users:(RX)
     Everyone:(Rc,S,RA)
     CREATOR OWNER:(OI)(CI)(IO)(F)
     CREATOR GROUP:(OI)(CI)(IO)(RX)
     NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(RX,W,DC)
     NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC)
     BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC)
     BUILTIN\Users:(OI)(CI)(IO)(RX)
     Everyone:(OI)(CI)(IO)(RX,W,DC)
     DOM\gratz:(OI)(CI)(F)

2 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler
aufgetreten.
(1023)...e/ADM_Backup_rsync/~2015-04-20_15~37 > getfacl .. . *
# file: ..
# owner: otheruser
# group: Domain Users
user::---
group::---
group:Authenticated Users:rwx
group:SYSTEM:rwx
group:Administrators:rwx
group:Users:r-x
mask:rwx
other:rwx
default:user::---
default:group::---
default:group:Authenticated Users:rwx
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:group:Users:r-x
default:mask:rwx
default:other:rwx

# file: .
# owner: gratz
# group: Domain Users
user::rwx
group::rwx
group:Authenticated Users:rwx
group:SYSTEM:rwx
group:Administrators:rwx
group:Users:r-x
mask:rwx
other:rwx
default:user::rwx
default:group::r-x
default:group:Authenticated Users:rwx
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:group:Users:r-x
default:mask:rwx
default:other:rwx

# file: dir1
# owner: gratz
# group: Domain Users
user::rwx
group::---
group:Authenticated Users:---
group:SYSTEM:rwx
group:Administrators:rwx
group:Users:---
mask:rwx
other:---
default:user::rwx
default:user:gratz:rwx
default:group::r-x
default:group:Authenticated Users:rwx
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:group:Users:r-x
default:mask:rwx
default:other:rwx

# file: dir2
# owner: gratz
# group: Domain Users
user::---
group::rwx
group:Authenticated Users:rwx
group:SYSTEM:rwx
group:Administrators:rwx
group:Users:r-x
mask:rwx
other:---
default:user::rwx
default:user:gratz:rwx
default:group::r-x
default:group:Authenticated Users:rwx
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:group:Users:r-x
default:mask:rwx
default:other:rwx

(1024).../Backup_rsync/~2015-04-20_15~37 > getfacl /cygdrive/x/dir1
# file: /cygdrive/x/dir1
# owner: otheruser
# group: Domain Users
user::---
group::---
group:ADM-FileOperators-L:rwx
group:PRJ-C-L:rwx
mask:rwx
other:---
default:user::---
default:group::---
default:group:ADM-FileOperators-L:rwx
default:group:PRJ-C-L:rwx
default:mask:rwx
default:other:---

(1025)...Backup_rsync/~2015-04-20_15~37 > getfacl /cygdrive/z/dir2
# file: /cygdrive/z/dir2
# owner: otheruser
# group: Domain Users
user::---
group::---
group:ADM-FileOperators-L:rwx
group:PRJ-R-L:r-x
group:PRJ-C-L:rwx
mask:rwx
other:---
default:user::---
default:group::---
default:group:ADM-FileOperators-L:rwx
default:group:PRJ-R-L:r-x
default:group:PRJ-C-L:rwx
default:mask:rwx
default:other:---


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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Corinna Vinschen]

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

On Apr 21 09:33, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > New 2.0.0-0.7 test release:
> 
> It looks like I found a bug or at least some extremely undesirable
> behaviour.  We back up some data via rsync, the script doesn't use the --acl
> option yet (that will need to change).  The bug happens without this option,
> so rsync tries to preserve the modes, which ends up making the files
> inaccessible.  The file share we back up from have ACL to grant the access
> only to certain groups and disallow to change the DACL.  In trying to get
> the modes set up in the same way, Cygwin rsync produces some DENY ACL that
> will completely lock me out (the windows GUI will not only complain about
> the order of ACL, it will also not show all ACL, so icacls is the only tool
> that can be used from that point forward).  I'm not really sure what rsync
> is doing here... it may need to become smarter about that possibility.

It's not about rsync exactly.  The problem is that I'm missing the
context a bit.  I take it the permissions are supposed to be inherited
from the ".." dir, basically.  The ".." dir has been created by
non-Cygwin means, right?  The "." dir has been created by Cygwin already
it seems, but what permissions were desired?  Does it match the
expectations or not?

The "dir1" and "dir2" directories both have been created by Cygwin,
but they are somehow totally wrong.  I don't see how this could occur,
even in case the ACL sorting fails at creation time.

Btw., the getfacl output of dir1 and dir2 don't seem to match the
icacls output.  The groups are different.

I wonder if I can create a similar scenario.  Reproducing might be
tricky :(


Corinna


> (1020)...Backup_rsync/~2015-04-20_15~37 > `cygpath -S`/icacls ..
> .. BUILTIN\Administrators:(I)(F)
>    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
>    NT AUTHORITY\SYSTEM:(I)(F)
>    NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
>    NT AUTHORITY\Authenticated Users:(I)(M)
>    NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
>    BUILTIN\Users:(I)(RX)
>    BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
>    Everyone:(I)(OI)(IO)(M,GA)
>    Everyone:(I)(CI)(F)
> 
> 1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler
> aufgetreten.
> (1021)...Backup_rsync/~2015-04-20_15~37 > `cygpath -S`/icacls .
> . NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
>   DOM\gratz:(F)
>   BUILTIN\Users:(DENY)(W,DC)
>   DOM\Domain Users:(RX,W,DC)
>   NT AUTHORITY\Authenticated Users:(RX,W,DC)
>   NT AUTHORITY\SYSTEM:(RX,W,DC)
>   BUILTIN\Administrators:(RX,W,DC)
>   BUILTIN\Users:(RX)
>   Everyone:(RX,W,DC)
>   NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,WEA,X,DC)
>   CREATOR OWNER:(OI)(CI)(IO)(F)
>   CREATOR GROUP:(OI)(CI)(IO)(DENY)(W,DC)
>   BUILTIN\Users:(OI)(CI)(IO)(DENY)(W,DC)
>   CREATOR GROUP:(OI)(CI)(IO)(RX)
>   NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(RX,W,DC)
>   NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC)
>   BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC)
>   BUILTIN\Users:(OI)(CI)(IO)(RX)
>   Everyone:(OI)(CI)(IO)(RX,W,DC)
> 
> 1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler
> aufgetreten.
> (1022)...Backup_rsync/~2015-04-20_15~37 > `cygpath -S`/icacls \*
> dir1 NULL SID:(DENY)(Rc,S,DC)
>      NT AUTHORITY\Authenticated Users:(DENY)(W,RD,REA,X,DC)
>      BUILTIN\Users:(DENY)(S,RD,REA,X)
>      NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,WEA,X,DC)
>      CREATOR GROUP:(OI)(CI)(IO)(DENY)(W,DC)
>      BUILTIN\Users:(OI)(CI)(IO)(DENY)(W,DC)
>      DOM\gratz:(D,Rc,WDAC,WO,RA,WA)
>      DOM\Domain Users:(Rc,S,RA)
>      NT AUTHORITY\Authenticated Users:(RX,W,DC)
>      NT AUTHORITY\SYSTEM:(RX,W,DC)
>      BUILTIN\Administrators:(RX,W,DC)
>      BUILTIN\Users:(RX)
>      Everyone:(Rc,S,RA)
>      CREATOR OWNER:(OI)(CI)(IO)(F)
>      CREATOR GROUP:(OI)(CI)(IO)(RX)
>      NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(RX,W,DC)
>      NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC)
>      BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC)
>      BUILTIN\Users:(OI)(CI)(IO)(RX)
>      Everyone:(OI)(CI)(IO)(RX,W,DC)
>      DOM\gratz:(OI)(CI)(F)
> 
> dir2 NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
>      DOM\gratz:(DENY)(S,RD,WD,AD,REA,WEA,X,DC)
>      NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,WEA,X,DC)
>      CREATOR GROUP:(OI)(CI)(IO)(DENY)(W,DC)
>      BUILTIN\Users:(OI)(CI)(IO)(DENY)(W,DC)
>      DOM\gratz:(D,Rc,WDAC,WO,RA,WA)
>      DOM\Domain Users:(RX,W,DC)
>      NT AUTHORITY\Authenticated Users:(RX,W,DC)
>      NT AUTHORITY\SYSTEM:(RX,W,DC)
>      BUILTIN\Administrators:(RX,W,DC)
>      BUILTIN\Users:(RX)
>      Everyone:(Rc,S,RA)
>      CREATOR OWNER:(OI)(CI)(IO)(F)
>      CREATOR GROUP:(OI)(CI)(IO)(RX)
>      NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(RX,W,DC)
>      NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC)
>      BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC)
>      BUILTIN\Users:(OI)(CI)(IO)(RX)
>      Everyone:(OI)(CI)(IO)(RX,W,DC)
>      DOM\gratz:(OI)(CI)(F)
> 
> 2 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler
> aufgetreten.
> (1023)...e/ADM_Backup_rsync/~2015-04-20_15~37 > getfacl .. . *
> # file: ..
> # owner: otheruser
> # group: Domain Users
> user::---
> group::---
> group:Authenticated Users:rwx
> group:SYSTEM:rwx
> group:Administrators:rwx
> group:Users:r-x
> mask:rwx
> other:rwx
> default:user::---
> default:group::---
> default:group:Authenticated Users:rwx
> default:group:SYSTEM:rwx
> default:group:Administrators:rwx
> default:group:Users:r-x
> default:mask:rwx
> default:other:rwx
> 
> # file: .
> # owner: gratz
> # group: Domain Users
> user::rwx
> group::rwx
> group:Authenticated Users:rwx
> group:SYSTEM:rwx
> group:Administrators:rwx
> group:Users:r-x
> mask:rwx
> other:rwx
> default:user::rwx
> default:group::r-x
> default:group:Authenticated Users:rwx
> default:group:SYSTEM:rwx
> default:group:Administrators:rwx
> default:group:Users:r-x
> default:mask:rwx
> default:other:rwx
> 
> # file: dir1
> # owner: gratz
> # group: Domain Users
> user::rwx
> group::---
> group:Authenticated Users:---
> group:SYSTEM:rwx
> group:Administrators:rwx
> group:Users:---
> mask:rwx
> other:---
> default:user::rwx
> default:user:gratz:rwx
> default:group::r-x
> default:group:Authenticated Users:rwx
> default:group:SYSTEM:rwx
> default:group:Administrators:rwx
> default:group:Users:r-x
> default:mask:rwx
> default:other:rwx
> 
> # file: dir2
> # owner: gratz
> # group: Domain Users
> user::---
> group::rwx
> group:Authenticated Users:rwx
> group:SYSTEM:rwx
> group:Administrators:rwx
> group:Users:r-x
> mask:rwx
> other:---
> default:user::rwx
> default:user:gratz:rwx
> default:group::r-x
> default:group:Authenticated Users:rwx
> default:group:SYSTEM:rwx
> default:group:Administrators:rwx
> default:group:Users:r-x
> default:mask:rwx
> default:other:rwx
> 
> (1024).../Backup_rsync/~2015-04-20_15~37 > getfacl /cygdrive/x/dir1
> # file: /cygdrive/x/dir1
> # owner: otheruser
> # group: Domain Users
> user::---
> group::---
> group:ADM-FileOperators-L:rwx
> group:PRJ-C-L:rwx
> mask:rwx
> other:---
> default:user::---
> default:group::---
> default:group:ADM-FileOperators-L:rwx
> default:group:PRJ-C-L:rwx
> default:mask:rwx
> default:other:---
> 
> (1025)...Backup_rsync/~2015-04-20_15~37 > getfacl /cygdrive/z/dir2
> # file: /cygdrive/z/dir2
> # owner: otheruser
> # group: Domain Users
> user::---
> group::---
> group:ADM-FileOperators-L:rwx
> group:PRJ-R-L:r-x
> group:PRJ-C-L:rwx
> mask:rwx
> other:---
> default:user::---
> default:group::---
> default:group:ADM-FileOperators-L:rwx
> default:group:PRJ-R-L:r-x
> default:group:PRJ-C-L:rwx
> default:mask:rwx
> default:other:---
> 
> 
> 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

-- 
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Achim Gratz]

Corinna Vinschen writes:
> It's not about rsync exactly.

Well, rsync creates that mess somehow.

> The problem is that I'm missing the
> context a bit.  I take it the permissions are supposed to be inherited
> from the ".." dir, basically.  The ".." dir has been created by
> non-Cygwin means, right?

Yes, it's the top-level directory of an external disk attached to USB.

> The "." dir has been created by Cygwin already
> it seems, but what permissions were desired?  Does it match the
> expectations or not?

All directories from here on down have been created by Cygwin / rsync,
and "." is the target directory of the rsync.

> The "dir1" and "dir2" directories both have been created by Cygwin,
> but they are somehow totally wrong.  I don't see how this could occur,
> even in case the ACL sorting fails at creation time.

The problem seems to be that without the --acl flag to rsync, it tries
to chmod the files it copies to the permissions it gets from the source
file (which would be ---rwx---+).

> Btw., the getfacl output of dir1 and dir2 don't seem to match the
> icacls output.  The groups are different.

Yes, that's likely a fallout from rsync trying to recreate the mode bits
for a different file owner and group.  On the source tree the file owner
(a domain user) doesn't have any rights, access is granted by one of the
share groups (seperately for read-only and modify access) and the filer
admin group (modify access plus a few more permissions).  None of the
share groups have permission to modify the DACL and everything gets
inherited from the root node of the share (it's a NetApp, but I don't
think that factors into that problem other than being the standard setup
on these files apparently).

> I wonder if I can create a similar scenario.  Reproducing might be
> tricky :(

Let me know if you need more information.


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

SD adaptation for Waldorf rackAttack V1.04R1:
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Corinna Vinschen]

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

On Apr 21 19:18, Achim Gratz wrote:
> Corinna Vinschen writes:
> > It's not about rsync exactly.
> 
> Well, rsync creates that mess somehow.
> 
> > The problem is that I'm missing the
> > context a bit.  I take it the permissions are supposed to be inherited
> > from the ".." dir, basically.  The ".." dir has been created by
> > non-Cygwin means, right?
> 
> Yes, it's the top-level directory of an external disk attached to USB.
> 
> > The "." dir has been created by Cygwin already
> > it seems, but what permissions were desired?  Does it match the
> > expectations or not?
> 
> All directories from here on down have been created by Cygwin / rsync,
> and "." is the target directory of the rsync.
> 
> > The "dir1" and "dir2" directories both have been created by Cygwin,
> > but they are somehow totally wrong.  I don't see how this could occur,
> > even in case the ACL sorting fails at creation time.
> 
> The problem seems to be that without the --acl flag to rsync, it tries
> to chmod the files it copies to the permissions it gets from the source
> file (which would be ---rwx---+).

Hmm.  Can you try the same with the latest developer snapshot I just
created?  I found this problem which created undesired DENY ACEs,
maybe this was the reason /knock on wood/.

But there's still the fact that the ACL isn't ordered the way Cygwin
intends to do it.  That points to another problem in ACL creation.
Either the ACL created at file creation time already hinders Cygwin
to set it straight afterwards, or the created ACL is missing something
so sorting fails.

> > Btw., the getfacl output of dir1 and dir2 don't seem to match the
> > icacls output.  The groups are different.
> 
> Yes, that's likely a fallout from rsync trying to recreate the mode bits
> for a different file owner and group.  On the source tree the file owner
> (a domain user) doesn't have any rights, access is granted by one of the
> share groups (seperately for read-only and modify access) and the filer
> admin group (modify access plus a few more permissions).  None of the
> share groups have permission to modify the DACL and everything gets
> inherited from the root node of the share

Oh well.

> (it's a NetApp, but I don't
> think that factors into that problem other than being the standard setup
> on these files apparently).
> 
> > I wonder if I can create a similar scenario.  Reproducing might be
> > tricky :(
> 
> Let me know if you need more information.

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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Achim Gratz]

Corinna Vinschen writes:
> Hmm.  Can you try the same with the latest developer snapshot I just
> created?  I found this problem which created undesired DENY ACEs,
> maybe this was the reason /knock on wood/.

I ran out of time, but I've managed to install the snapshot and did a
quick test before going home.  The ACL looks saner than before and I can
regain access via chmod, so that's good.  The basic problem however
remains and I'm really not sure if that's a bug in rsync or in Cygwin or
even a bug at all.

The file to be copied has, as stated before, access granted only via a
share group (actually three of them, but that's not a factor).  So
CREATOR OWNER, CREATOR group, the original owner of the file and myself
(owner of the newly created file) have no DACL entry on the original
file and the resulting file mode is "---rwx---+".  For "rsync -av" this
means that after the copy the mode is set to 0060 and that explicitly
locks out (via DENY) CREATOR OWNER CREATOR GROUP and myself.  That gives
the same POSIX modes, but not the same access rights of course.  For
"rsync -av --acls" the same happens and then some ACL are copied over
from the original file, which still doesn't get me access since the
DENY ACL is first in the list.

This might be a hole in the ACL mapping to POSIX file modes.  The way I
see it the reported file mode should actually be "rwxrwx---+" for the
original file since that's the effective access granted by Windows and
there are no POSIX flags on the original file (via NULL SID).  Just like
on POSIX (where it's done via mask) the user flags can only be cleared
in this situation by an explicit chmod (which then gets implemented via
DENY ACL I suppose).


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Corinna Vinschen]

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

On Apr 22 20:35, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Hmm.  Can you try the same with the latest developer snapshot I just
> > created?  I found this problem which created undesired DENY ACEs,
> > maybe this was the reason /knock on wood/.
> 
> I ran out of time, but I've managed to install the snapshot and did a
> quick test before going home.  The ACL looks saner than before and I can
> regain access via chmod, so that's good.  The basic problem however
> remains and I'm really not sure if that's a bug in rsync or in Cygwin or
> even a bug at all.
> 
> The file to be copied has, as stated before, access granted only via a
> share group (actually three of them, but that's not a factor).  So
> CREATOR OWNER, CREATOR group, the original owner of the file and myself
> (owner of the newly created file) have no DACL entry on the original
> file and the resulting file mode is "---rwx---+".  For "rsync -av" this
> means that after the copy the mode is set to 0060 and that explicitly
> locks out (via DENY) CREATOR OWNER CREATOR GROUP and myself.  That gives
> the same POSIX modes, but not the same access rights of course.  For
> "rsync -av --acls" the same happens and then some ACL are copied over
> from the original file, which still doesn't get me access since the
> DENY ACL is first in the list.
> 
> This might be a hole in the ACL mapping to POSIX file modes.  The way I
> see it the reported file mode should actually be "rwxrwx---+" for the
> original file since that's the effective access granted by Windows and
> there are no POSIX flags on the original file (via NULL SID).  Just like
> on POSIX (where it's done via mask) the user flags can only be cleared
> in this situation by an explicit chmod (which then gets implemented via
> DENY ACL I suppose).

You may be right here.  The problem is that we have two kinds of ACLs
to handle, the ones created by Windows means, and the ones created
by recent or older Cygwin versions.  It's rather bad that we can't
distinguish them.

But then, how do you check an arbitrary ACL for the effective rights
it creates for all affected parties?  I may be missing some API function.
but I don't see a Windows function generating some kind of effective
ACL.  There's only the function AccessCheck() which gets a token and an
ACL as input and then tells you the effective rights of the user with
this token.  This gets very slow and complicated, very quickly.

I hate to admit defeat, but it also seems that the method I used to
handle real vs. effective rights just doesn't work as desired.  In
theory we don't want the DENY ACEs having any effect before visiting the
ALLOW ACEs.

Ideally the DENY ACEs should only point out what the real access rights
are, and they should secure the access against the next group, along
the lines of

  NULL     DENY
  user1    ALLOW	# Only effective rights
  user2    ALLOW	# ...
  user1    DENY		# Point out real permissions, somehow
                          Secure against excess group permissions
  user2    DENY		# ...
  group1   ALLOW	# As above
  group2   ALLOW	# ...
  group1   DENY		# As above, secure against excess Everyone perms
  group2   DENY		# ...
  other    ALLOW

This needs yet another rewrite, but this will take a lot longer than
this first cut.  I guess we should create a new Cygwin release without
this new ACL handling change for now to get the bugfixes out.


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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Achim Gratz]

Corinna Vinschen writes:
> You may be right here.  The problem is that we have two kinds of ACLs
> to handle, the ones created by Windows means, and the ones created
> by recent or older Cygwin versions.  It's rather bad that we can't
> distinguish them.

I thought that this was the point of the NULL SID ACL entries?

> But then, how do you check an arbitrary ACL for the effective rights
> it creates for all affected parties?  I may be missing some API function.
> but I don't see a Windows function generating some kind of effective
> ACL.  There's only the function AccessCheck() which gets a token and an
> ACL as input and then tells you the effective rights of the user with
> this token.  This gets very slow and complicated, very quickly.

Right.

> I hate to admit defeat, but it also seems that the method I used to
> handle real vs. effective rights just doesn't work as desired.  In
> theory we don't want the DENY ACEs having any effect before visiting the
> ALLOW ACEs.
[…]

I don't think the ACL rules on Windows are made for that due to the
early-out aspect of their semantics.

> This needs yet another rewrite, but this will take a lot longer than
> this first cut.  I guess we should create a new Cygwin release without
> this new ACL handling change for now to get the bugfixes out.

Yes, getting the fixes out and shelving the ACL part for some
re-thinking seems like a good idea.


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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Corinna Vinschen]

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

On Apr 23 20:44, Achim Gratz wrote:
> Corinna Vinschen writes:
> > You may be right here.  The problem is that we have two kinds of ACLs
> > to handle, the ones created by Windows means, and the ones created
> > by recent or older Cygwin versions.  It's rather bad that we can't
> > distinguish them.
> 
> I thought that this was the point of the NULL SID ACL entries?

I was referring to the old-style ACLs created by Cygwin.  There
are some subtil differences.  I have to think about that some more if
that difference is really relevant.  It's a dangerous job since Windows
ACLs can cause knots in the brain.

> > But then, how do you check an arbitrary ACL for the effective rights
> > it creates for all affected parties?  I may be missing some API function.
> > but I don't see a Windows function generating some kind of effective
> > ACL.  There's only the function AccessCheck() which gets a token and an
> > ACL as input and then tells you the effective rights of the user with
> > this token.  This gets very slow and complicated, very quickly.
> 
> Right.

For the records:  AuthZ *might* be the answer.  I never used it and
I need some serious reading up on it.

> > I hate to admit defeat, but it also seems that the method I used to
> > handle real vs. effective rights just doesn't work as desired.  In
> > theory we don't want the DENY ACEs having any effect before visiting the
> > ALLOW ACEs.
> […]
> 
> I don't think the ACL rules on Windows are made for that due to the
> early-out aspect of their semantics.

Yes, that's why the ordering is relevant.  If the deny's follow the
allows, they are almost (but not entirely) irrelevant.  Thus they
can be used to store information.

> > This needs yet another rewrite, but this will take a lot longer than
> > this first cut.  I guess we should create a new Cygwin release without
> > this new ACL handling change for now to get the bugfixes out.
> 
> Yes, getting the fixes out and shelving the ACL part for some
> re-thinking seems like a good idea.

Yup.


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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[random user]

Let me take a try on Achim's case with/refining the "alternative
idea"; this seems one of the kinds of cases that it is intended to
help.

(Corinna, I hope at least some of the ideas here prove helpful to you,
and my posting this isn't (too) annoying.  Again, please
expect/forgive glitches as I'm not an expert on the internals of the
Cygwin library nor are file ACLs directly my area of expertise.  I've
included a lot of detail to try to see for myself if the pieces would
seem to all fit together properly, but to whatever extent those
details don't match possible reality, please try to see the abstract
idea/goal of supporting coexisting purely Windows-behaved and purely
Posix-behaved ACL entries.)

(Achim, I would be interested in hearing how well this approach would
seem to serve your needs/desires; there's a summary of the resulting
behavior for this case in the last main paragraph below.)

>> On the source tree the file owner (a domain user) doesn't have any
   rights, access is granted by one of the share groups (separately
   for read-only and modify access) and the filer admin group (modify
   access plus a few more permissions).  None of the share groups have
   permission to modify the DACL and everything gets inherited from
   the root node of the share (it's a NetApp, but I don't think that
   factors into that problem other than being the standard setup on
   these files apparently).

Here the "share group"(s) and "filer admin" seem examples of ACL
entries that are intended to behave following Windows, not Posix,
behavior.  I would expect the most desired behavior would be that they
would be inherited onto any newly-created files in those directories
following Windows' behavior, without at all impacting Posix behavior
such as whether (creation mode & ~umask) should be applied.  That they
would best not be impacted at all by chmod, or by setfacl creating a
Posix mask.  And that Cygwin/GNU tools such as rsync, also cp, tar,
etc., would best not carry these non-Posix-behaved/Windows-purposed
ACL entries from one directory subtree to another, but rather carry
across only Posix-behaved permission mode and "extended ACLs" plus
fold in whatever non-Posix to-be-inherited entries are present on the
target directory.

To achieve that, in this "alternative idea" the correct Posix mode for
this particular (extreme) case described by Achim would be --------- =
0000.  Similarly, getfacl would not show the "share group"(s), "filer
admin", or SYSTEM, ADMINISTRATORS, USERS, AUTHENTICATED USERS,
etc. ACL entries in this example at all (none of these are the primary
group, none of these are created with new-version setfacl).  The
impacts of these non-Posix-behaved ACL entries would be visible via
Cygwin/Posix APIs only the same as Linux shows impacts of root's
"magic" rights.

I would expect the lack of visibility of all granted permissions to be
an aspect some folks won't like about this "alternative idea" model,
but it seems necessary for ~/.ssh and similar cases to behave as
multiple people seem to be requesting, for chmod to have the visible
effects that it should without actually impacting these
non-Posix-behaved ACL entries, and for (creation mode & ~umask) to be
applied or not based on whether there are any Posix-"extended ACLs"
group/default entries but not impacted by non-Posix-behaved ACL
entries.  icacls would be the program to use if wanting to see
non-Posix-behaved ACL entries, tho perhaps getfacl could have an
option with some special-case code involved to be able to display
these, ideally marked as '#non-Posix' or some such.

At the Windows ACL level, this case does point out the need to be
quite careful about ordering.  Assuming Windows stops on the first
match it finds for an ACL entry the current user token and desired
kind of access matches, it would seem the non-Posix-behaved ACL
entries need merely to be kept earlier in the ACL than any
Posix-masked entries to avoid being impacted by the Posix-mask DENYs.
I've also thought through a little more re non-Posix-behaved DENY
cases; I now think they can coexist with Posix-behaved masking if we
locate the NULL SID carefully and choose (as I think is likely what'd
be most wanted by the Windows administrator) that any
non-Posix-behaved DENY should have priority over any Posix-behaved
permission grant.

Thus I'm thinking the best ACL ordering would be

  non-Posix-behaved ACL entries
  NULL SID
  owner
  primary group
  other Posix-behaved users/groups (all referred to below as "groups")
  others/Everyone

To-be-inherited markings/entries should be kept in/following the same
active-for-this-file case/SID above, in particular, all
to-be-inherited-as-non-Posix-behaved ACL entries would precede the
NULL SID marker, Posix-behaved default entries after.

The Posix-behaved group entries should have a DENY preceding their
ALLOW if and only if by Posix rules a mask should exist.  The value of
the mask seems just the inverse of what the DENYs deny, which it seems
can be written the same for all the Posix-behaved groups without being
dependent on what permissions that group's ALLOW would have.  If any
DENY are present for Posix-behaved groups, they would all be expected
to represent the same one mask value, so there would seem no
importance to the ordering amongst Posix-behaved groups other than
that the related DENY precede each ALLOW.  Representing the mask
within the NULL SID entry also as Corinna wrote about earlier would
seem not necessary, but not harmful.

When reading a Windows ACL, the Cygwin library would start off
processing the types of ACL entries it has historically treated as
owner, primary group, and others, but simply ignoring all other
entries unless/until it sees the NULL SID marker.  At that point it
would process all the remainder, treating them as Posix-behaved.

When writing a Windows ACL, Cygwin would want to start by
copying/keeping existing ACL entries the file/directory has, but
filtering out any it considers owner/primary group/others, until it
hits the end of the ACL or the NULL SID entry.  At that which point,
stop copying what previously exists and instead write values per the
now-desired Posix mode and Posix-behaved set of ACL entries.  Whether
the copying/keeping of early entries should remove any
non-Posix-behaved ACL entries with the same SIDs as Posix-behaved ones
that are to be written seems a choice that could be made in either
direction.

This would all seem to work pretty well assuming the non-Posix-behaved
ACL entries are always created on a directory tree before Cygwin
starts writing into it.  I am uncomfortable tho about what would
happen should someone apply icacls or Windows GUI changes *after*
Cygwin has created an ACL with Posix-behaved additional groups or
defaults.  I'd expect problems, especially with the Windows GUI if I
recall correctly that it reorders ACL entries.  But even using icacls
to add a new non-Posix-behaved entry would appear to be difficult, as
it doesn't seem to have any "put this first" kind of option that I
spot, rather only wants to keep all ALLOWs after all DENYs.  Cygwin
might provide some special option/code in setfacl or some distinct
program to help maintenance, but a Windows admin might just use the
Windows tools regardless, causing effective corruption.

To ease this concern, the NULL SID should be written preceding the
Posix-behaved items if and only if there are any Posix-behaved added
groups, Posix-behaved defaults, or Posix mask present.  No NULL SID
should be written if only non-Posix-behaved ACL entries plus simple
owner/primary group/others Posix mode permissions need to be
represented.  This way icacls and Windows GUI would remain safe for
use modifying any file/directory that has not had explicit new-version
setfacl activity; any new ACL entries they'd create would be properly
treated as non-Posix-behaved.  Reordering might mess up the
owner/primary group/others ordering necessary for precise Posix
semantics, but that would seem an already existing problem and for the
most typical cases of naturally decreasing rights not a real concern.

Summarizing for Achim's particular case, the behavior would be simply
that the target new files/directories would get only ACL entries as
defined by the non-Posix-behaved to-be-inherited ACL entries of their
target parent directory, followed by an ALLOW of (Rc,S,RA) to each of
file owner, primary group, and Everyone, representing the 0000 Posix
mode (assuming rsync is creating target files/dirs with, or after
creation chmods them to, the 0000 Posix mode matching the source; else
(creation mode & ~umask) would be represented).  No other ACL entries
from the source files would be copied over to the targets.  For this
case, no NULL SID nor any DENYs would be created.

Thanks again for considering these thoughts.


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