* [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 @ 2015-04-17 11:03 Corinna Vinschen 2015-04-17 20:10 ` Achim Gratz 2015-04-21 9:33 ` Achim Gratz 0 siblings, 2 replies; 17+ messages in thread From: Corinna Vinschen @ 2015-04-17 11:03 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-17 11:03 [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 Corinna Vinschen @ 2015-04-17 20:10 ` Achim Gratz 2015-04-18 8:39 ` Corinna Vinschen 2015-04-21 9:33 ` Achim Gratz 1 sibling, 1 reply; 17+ messages in thread From: Achim Gratz @ 2015-04-17 20:10 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-17 20:10 ` Achim Gratz @ 2015-04-18 8:39 ` Corinna Vinschen 2015-04-18 9:47 ` Achim Gratz 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2015-04-18 8:39 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-18 8:39 ` Corinna Vinschen @ 2015-04-18 9:47 ` Achim Gratz 2015-04-18 10:20 ` Corinna Vinschen 0 siblings, 1 reply; 17+ messages in thread From: Achim Gratz @ 2015-04-18 9:47 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-18 9:47 ` Achim Gratz @ 2015-04-18 10:20 ` Corinna Vinschen 2015-04-18 10:48 ` Achim Gratz 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2015-04-18 10:20 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-18 10:20 ` Corinna Vinschen @ 2015-04-18 10:48 ` Achim Gratz 2015-04-18 11:07 ` Corinna Vinschen 0 siblings, 1 reply; 17+ messages in thread From: Achim Gratz @ 2015-04-18 10:48 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-18 10:48 ` Achim Gratz @ 2015-04-18 11:07 ` Corinna Vinschen 2015-04-19 6:05 ` Achim Gratz 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2015-04-18 11:07 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-18 11:07 ` Corinna Vinschen @ 2015-04-19 6:05 ` Achim Gratz 0 siblings, 0 replies; 17+ messages in thread From: Achim Gratz @ 2015-04-19 6:05 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-17 11:03 [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 Corinna Vinschen 2015-04-17 20:10 ` Achim Gratz @ 2015-04-21 9:33 ` Achim Gratz 2015-04-21 12:16 ` Corinna Vinschen 1 sibling, 1 reply; 17+ messages in thread From: Achim Gratz @ 2015-04-21 9:33 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-21 9:33 ` Achim Gratz @ 2015-04-21 12:16 ` Corinna Vinschen 2015-04-21 17:19 ` Achim Gratz 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2015-04-21 12:16 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-21 12:16 ` Corinna Vinschen @ 2015-04-21 17:19 ` Achim Gratz 2015-04-22 9:04 ` Corinna Vinschen 0 siblings, 1 reply; 17+ messages in thread From: Achim Gratz @ 2015-04-21 17:19 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-21 17:19 ` Achim Gratz @ 2015-04-22 9:04 ` Corinna Vinschen 2015-04-22 18:35 ` Achim Gratz 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2015-04-22 9:04 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-22 9:04 ` Corinna Vinschen @ 2015-04-22 18:35 ` Achim Gratz 2015-04-23 8:34 ` Corinna Vinschen 0 siblings, 1 reply; 17+ messages in thread From: Achim Gratz @ 2015-04-22 18:35 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-22 18:35 ` Achim Gratz @ 2015-04-23 8:34 ` Corinna Vinschen 2015-04-23 18:45 ` Achim Gratz 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2015-04-23 8:34 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-23 8:34 ` Corinna Vinschen @ 2015-04-23 18:45 ` Achim Gratz 2015-04-23 19:49 ` Corinna Vinschen 0 siblings, 1 reply; 17+ messages in thread From: Achim Gratz @ 2015-04-23 18:45 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-23 18:45 ` Achim Gratz @ 2015-04-23 19:49 ` Corinna Vinschen 2015-04-24 2:14 ` random user 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2015-04-23 19:49 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-23 19:49 ` Corinna Vinschen @ 2015-04-24 2:14 ` random user 0 siblings, 0 replies; 17+ messages in thread From: random user @ 2015-04-24 2:14 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-04-24 2:14 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-17 11:03 [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 Corinna Vinschen 2015-04-17 20:10 ` Achim Gratz 2015-04-18 8:39 ` Corinna Vinschen 2015-04-18 9:47 ` Achim Gratz 2015-04-18 10:20 ` Corinna Vinschen 2015-04-18 10:48 ` Achim Gratz 2015-04-18 11:07 ` Corinna Vinschen 2015-04-19 6:05 ` Achim Gratz 2015-04-21 9:33 ` Achim Gratz 2015-04-21 12:16 ` Corinna Vinschen 2015-04-21 17:19 ` Achim Gratz 2015-04-22 9:04 ` Corinna Vinschen 2015-04-22 18:35 ` Achim Gratz 2015-04-23 8:34 ` Corinna Vinschen 2015-04-23 18:45 ` Achim Gratz 2015-04-23 19:49 ` Corinna Vinschen 2015-04-24 2:14 ` random user
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).