[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
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 - 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/set
Re: TEST RELEASE: Cygwin 2.0.0-0.7
> New 2.0.0-0.7 test release: I'm happy to report that Xwin now starts up straight away, even with "missing" /etc/passwd and /etc/group files. Thanks for fixing this! -- Jim Reisert AD1C, , http://www.ad1c.us -- 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: TEST RELEASE: Cygwin 2.0.0-0.7
There's still something funky going on. ssh won't recognize my ~/.ssh/config file. With my existing passwd and group files, I get this error (notice that the warned permissions are different that what "ls" reports): -rw---+ 1 Jim Reisert None 205 Apr 17 06:19 .ssh/config [JJR:~] $ ssh ad1c @@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@ Permissions 0644 for '/cygdrive/D/home/.ssh/id_rsa' are too open. It is recommended that your private key files are NOT accessible by others. This private key will be ignored. Load key "/cygdrive/D/home/.ssh/id_rsa": bad permissions If I move both passwd and group out-of-the-way, the config file is not recognized at all! -rw---+ 1 Jim Reisert None 205 Apr 17 06:19 .ssh/config [JJR:~] $ ssh ad1c ssh: Could not resolve hostname ad1c: Name or service not known -- Jim Reisert AD1C, , http://www.ad1c.us -- 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: TEST RELEASE: Cygwin 2.0.0-0.7
On Apr 17 06:15, Jim Reisert AD1C wrote: > > New 2.0.0-0.7 test release: > > I'm happy to report that Xwin now starts up straight away, even with > "missing" /etc/passwd and /etc/group files. > > Thanks for fixing this! Sure, thanks for your feedback! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpG82d_JBGSF.pgp Description: PGP signature
Re: TEST RELEASE: Cygwin 2.0.0-0.7
On Apr 17 06:27, Jim Reisert AD1C wrote: > There's still something funky going on. ssh won't recognize my > ~/.ssh/config file. > > With my existing passwd and group files, I get this error (notice that > the warned permissions are different that what "ls" reports): > > -rw---+ 1 Jim Reisert None 205 Apr 17 06:19 .ssh/config > > [JJR:~] $ ssh ad1c > @@@ > @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ > @@@ > Permissions 0644 for '/cygdrive/D/home/.ssh/id_rsa' are too open. ^^ Another file? > It is recommended that your private key files are NOT accessible by others. > This private key will be ignored. > Load key "/cygdrive/D/home/.ssh/id_rsa": bad permissions > > > If I move both passwd and group out-of-the-way, the config file is not > recognized at all! > > -rw---+ 1 Jim Reisert None 205 Apr 17 06:19 .ssh/config > > [JJR:~] $ ssh ad1c > ssh: Could not resolve hostname ad1c: Name or service not known I don't understand the reason for this message. It does not exactly point to a problem with the config file. I think I need more explanation here and a bit of detective work from your side... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpxKHZNfvIRo.pgp Description: PGP signature
Re: TEST RELEASE: Cygwin 2.0.0-0.7
I finally understand what happened. In my /etc/passwd, I have configured a different home directory for myself. Without that file, it goes to /home/Jim Reisert which does not exist! Is there a way to change my default home directory without using /etc/passwd, other than creating a symbolic link inside of /home? - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- 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: TEST RELEASE: Cygwin 2.0.0-0.7
On Apr 17 06:46, Jim Reisert AD1C wrote: > I finally understand what happened. > > In my /etc/passwd, I have configured a different home directory for > myself. Without that file, it goes to /home/Jim Reisert which does > not exist! > > Is there a way to change my default home directory without using > /etc/passwd, other than creating a symbolic link inside of /home? That's what is explained in https://cygwin.com/cygwin-ug-net/ntsec.html The chapters you should be looking for are https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-home E.g. this setting in /etc/nsswitch.conf would do the trick if you're the only user (but careful with sshd!): Or perhaps https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-desc Set "db_home: desc" and change the description field in your SAM according to the above document. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpKujJ8fLeGQ.pgp Description: PGP signature
Re: TEST RELEASE: Cygwin 2.0.0-0.7
On Apr 17 15:16, Corinna Vinschen wrote: > On Apr 17 06:46, Jim Reisert AD1C wrote: > > I finally understand what happened. > > > > In my /etc/passwd, I have configured a different home directory for > > myself. Without that file, it goes to /home/Jim Reisert which does > > not exist! > > > > Is there a way to change my default home directory without using > > /etc/passwd, other than creating a symbolic link inside of /home? > > That's what is explained in https://cygwin.com/cygwin-ug-net/ntsec.html > > The chapters you should be looking for are > > https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-home > > E.g. this setting in /etc/nsswitch.conf would do the trick if you're > the only user (but careful with sshd!): db_home: /cygdrive/d/home > Or perhaps > > https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-desc > > Set "db_home: desc" and change the description field in your SAM > according to the above document. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgptASafg3ZTk.pgp Description: PGP signature
Re: TEST RELEASE: Cygwin 2.0.0-0.7
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-home Very helpful, Corinna! Working as advertised. - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- 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: TEST RELEASE: Cygwin 2.0.0-0.7
On Fri, Apr 17, 2015 at 7:46 AM, Jim Reisert AD1C wrote: > Is there a way to change my default home directory without using > /etc/passwd, other than creating a symbolic link inside of /home? You can modify /etc/fstab like this c:/home /home . acl Example http://github.com/svnpenn/dotfiles/blob/24302d29ef7158df1aa3a584131c810/fstab#L2 -- 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 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) (0x42) 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 00C3 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 2 [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) (0x42) 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 00C3 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) (0x42) 23 47243 [main] find 3992
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
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 pgph4m1DUmWmS.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
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
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 pgpGcLfpLq2nS.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
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
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 pgpX8oW2Vh5xx.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
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
Corinna Vinschen 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:--- defau
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
On Apr 21 09:33, Achim Gratz wrote: > Corinna Vinschen 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. > (10
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
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
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 pgpyz6vkL3ZUS.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
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
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 user1ALLOW# Only effective rights user2ALLOW# ... user1DENY # Point out real permissions, somehow Secure against excess group permissions user2DENY # ... group1 ALLOW# As above group2 ALLOW# ... group1 DENY # As above, secure against excess Everyone perms group2 DENY # ... otherALLOW 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 pgppUC2uNjzRQ.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
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
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 pgpcJCp2nmwNz.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
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 - = . 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
issues seen in TEST RELEASE: Cygwin 2.0.0-0.7
Hi again, Corinna. I appreciate these recent changes, the more complete Posix ACL support looks beneficial for sharing/syncing files between Cygwin and Linux machines, and for more compatible scripting. But I've noticed a few possibly-concerning items: Item 1: >> - I introduced a change in chmod behaviour which is not exactly in line with POSIX 1003.1e draft 17: This change looks to me to be somewhat dangerous. I'm concerned it may lead to granting privileges one doesn't expect to have granted. And scripts leveraging this would behave noticeably differently on Cygwin than they do on Linux, leading to extra time to debug/recode. A simplistic example use case: # Create scripts for some app, with group set to give httpd or some # other application login user read and execute privs. For sake of # brevity, here only showing one directory, but reality would likely # be a tree of dirs and files. At least to my sensibilities, having # the primary group be httpd here makes sense in what I'd like to see # in 'ls', and what I'd like 'find' to be able to find most easily, # even tho httpd is intended to have fewer privileges than the # developers group will be given at times on these dirs/files. mkdir appdir chgrp httpd appdir chmod 750 appdir ls -ald appdir getfacl appdir # Give developers write access. setfacl -m "g:developers:rwx" appdir ls -ald appdir getfacl appdir # Production use period, try to prevent changes. chmod ugo-w appdir ls -ald appdir getfacl appdir # Development period: Reenable changes by local-machine developers - # but did NOT intend to enable writes from the http daemon which may # be up running other applications. On Linux, remains 'group::r-x', # only mask gets changed. chmod g+w appdir ls -ald appdir getfacl appdir --- Item 2: I'm having troubles figuring out how to create a directory that plays well both for providing old-style umask behavior and as a holder of files created by non-Cygwin Windows apps. Cygwin mkdir seems to create some to-be-inherited ACLs, even if the parent directory has had 'setfacl -k' applied (and so it's clear these aren't being inherited down, they seem newly added by mkdir or some library call it makes): CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX,W,DC) Everyone:(OI)(CI)(IO)(RX,W,DC) (The actual permissions in these seem to vary based on the umask setting and any inherited ACLs at time of directory creation.) This seems existing behavior in Cygwin, still present in this test drop. What I seem to be seeing is that with these present, this test drop appears to now be treating the directory as having "extended ACLs" (is that the proper phrasing?), and so now will use these default: ACL entries to create the permissions for a newly-created-by-Cygwin-app file rather than using umask. So even with umask = 0, I now get only 0700 on newly created files in a directory that itself has 0700, rather than 0777 as I get on older Cygwin and on Linux. (What I actually get seems to vary based on the directory-creation-time umask, or whatever ACLs the parent directory itself inherited via this mechanism, as noted in prior paragraph's parenthetical.) I can use 'setfacl -k .' to remove these, but then if I try to write a file into the directory using a non-Cygwin program I end up with a rather strange set of ACLs on it. (I had in past remembered stuff like "CURRENT SESSION", but doing a test now using 'echo x > file' under cmd I find I get (F), cyg_server(F), Administrators(F), and SYSTEM(F) tho none of cyg_server, Administrators, nor SYSTEM are present at all in the ACLs of the parent directory, and isn't cyg_server.) I suspect the desire to allow non-Cygwin apps to sanely create files in a Cygwin-created directory is likely the reason that mkdir is creating these ACL entries. Would it maybe make sense for 'setfacl -k' to keep/recreate the same base set of to-be-inherited ACLs that mkdir does, and for the determination of whether to use umask vs. the default: ACLs to ignore these? Maybe for better cosmetics, for getfacl to not show these, nor ls to show these cases only as causing a '+' to appear, so that a newly-created directory with no ACLs inherited from above would appear both visually and behaviorally as not using "extended ACLs"? I note that chmod doesn't keep these to-be-inherited entries in sync with the directory's mode; they seem stuck at their create-time values unless changed explicitly with icacls. (And am I right that these can't be easily changed with setfacl, since the SIDs involved don't have Cygwin user/group mappings?) This seems true of both this test drop and older Cygwin. Intuitively this feels not-quite-right, but seems a separable concern from the above and isn't a current change. --- Item 3: It seems to create rather messy/redundant ACLs if one tries to use setfacl to adjust the owning user's privileges explicitly by user name. This is also seeming to be interacting with the "Item 1" topic, l
Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7
Hi random user (at least a first name would be nice, you know my first name as well, isn't it?), On Apr 17 22:58, random user wrote: > Hi again, Corinna. > > I appreciate these recent changes, the more complete Posix ACL support > looks beneficial for sharing/syncing files between Cygwin and Linux > machines, and for more compatible scripting. > > But I've noticed a few possibly-concerning items: > > Item 1: > > >> - I introduced a change in chmod behaviour which is not exactly in > line with POSIX 1003.1e draft 17: > > This change looks to me to be somewhat dangerous. I'm concerned it > may lead to granting privileges one doesn't expect to have granted. > And scripts leveraging this would behave noticeably differently on > Cygwin than they do on Linux, leading to extra time to debug/recode. > > A simplistic example use case: Ok, I understand the concern here, but I really didn't do that change out of the blue. Maybe I'm just dumb, but I puzzled myself with this behaviour a couple of times. I think that this specific behaviour defined in draft 17 is surprising for the end user. The difference between Linux and Cygwin is that Cygwin users have *lots* of ACLs with default permissions for secondary users by default while on Linux this feature is used in limited circumstances. So without this change, what Cygwin users get is something like this by default: $ touch foo $ chmod g+w foo [switch to another user, member in the same group] $ echo bar >> foo echo: Permission denied A Linux user will never encounter this behaviour in the default case. This is what concerns me a lot and what triggered this change. I'm willing to rethink this change, but for the time being I'd like to keep it this way and test it with a bigger user base (not only the few testers). > Item 2: > > I'm having troubles figuring out how to create a directory that plays > well both for providing old-style umask behavior and as a holder of > files created by non-Cygwin Windows apps. Yeah, I know what you mean. Here's another example of following 1003.1e to the letter while at the same time trying to accommodate native Windows applications... > (The actual permissions in these seem to vary based on the umask > setting and any inherited ACLs at time of directory creation.) > This seems existing behavior in Cygwin, still present in this > test drop. (This is very old code. Windows applications rely on inherited ACLs, so creating Cygwin folders POSIX style, without inhertable ACEs, will result in weird permission settings for files created with native tools) > What I seem to be seeing is that with these present, this test drop > appears to now be treating the directory as having "extended ACLs" (is > that the proper phrasing?), (default ACL entries in POSIX speak, inheritable ACEs in Windows) > and so now will use these default: ACL > entries to create the permissions for a newly-created-by-Cygwin-app > file rather than using umask. ...the 1003.1e part being to apply the umask only if the file does not come with inherited permissions. Due to the default ACEs created by default, all files will have inherited permissions and thus umask is seldomly applied. Yes, that's a problem. The underlying problem is that you can't distinguish inheritable ACEs created by Cygwin just for the sake of Windows applications from inheritable ACEs created explicitely and willingly to have the same behaviour for Cygwin apps. They are identical to the bit. So it's not clear in this scenario when to apply umask. From the 1003.1e perspective the code is doing the right thing, but the result may, again, be surprising. Any suggestions? Always applying umask, no matter what? > I can use 'setfacl -k .' to remove these, but then if I try to write a > file into the directory using a non-Cygwin program I end up with a > rather strange set of ACLs on it. Typically you get the default DACL from your user token: $USER rwx SYSTEM rwx Admins rwx > I suspect the desire to allow non-Cygwin apps to > sanely create files in a Cygwin-created directory is likely the reason > that mkdir is creating these ACL entries. As outlined above. > Would it maybe make sense for 'setfacl -k' to keep/recreate the same > base set of to-be-inherited ACLs that mkdir does, and for the > determination of whether to use umask vs. the default: ACLs to ignore > these? Maybe for better cosmetics, for getfacl to not show these, nor > ls to show these cases only as causing a '+' to appear, so that a > newly-created directory with no ACLs inherited from above would appear > both visually and behaviorally as not using "extended ACLs"? No. I really don't think so. Again, the point is that you can't inherited ACEs for Windows-only from explicit default ACL entries created by a user. Second guessing here and not showing entries will even be more surprising. > I note that chmod doesn't keep these to-be-inherited entries in sync > with the directory's m
Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7
Hmm... Seems my Item 1 and Item 2 are more related in your design thinking than I had realized. >>> "extended ACLs" (is that the proper phrasing?), >> (default ACL entries in POSIX speak, inheritable ACEs in Windows) I'm looking for the term that would distinguish whether on Linux ls shows a '+' and getfacl shows a mask: line, and controls whether umask is ignored or respected and how chmod behaves -- which seems on Linux whether any ACL entry other than those needed to represent the basic mode are present. I'll stick with "extended ACLs" for this below; Google seems to show many hits with this intended meaning on that phrase. >>> I note that chmod doesn't keep these to-be-inherited entries in sync with the directory's mode; >>Yep. Did you check against Linux behaviour? The difference to my eye is that on Linux there is no such to-be-inherited CREATOR OWNER ACL entry created implicitly by mkdir. If there is one existing, it's because it was created explicitly with setfacl, so seems more the user's responsibility to maintain. >> Any suggestions? Always applying umask, no matter what? Please, no. That would create a behavior pattern quite different than Linux's. I don't myself like some aspects of the Linux/Posix behavior, but, at least to me, having Cygwin behave compatibly so that code/scripts behave the same on Cygwin as on Linux is way more important. (Please read this paragraph also as my reply to you re the Item 1 topic.) Tho, to be precise: I think I am seeing on Linux that umask is always applied, just it is applied differently depending on whether any default ACL entries are present on the parent directory: a1) on Linux, if there are any default ACL entries on the parent directory, umask is applied to these. Execute perms are then also dropped when creating a new non-directory. a2) on Linux, if there are no default ACL entries on the parent directory, umask is applied to 0777. Execute perms are then also dropped when creating a new non-directory. b) in current/older Cygwin releases, umask is applied to 0777. Execute perms are then also dropped when creating a new non-directory. The result is then combined with any to-be-inherited ACL entries from the parent directory. Does that all seem correct? As to a suggestion OK, I'll toss out a strawman. Maybe it'll be food for thought, parts of it useful, even if you don't like/choose the entire approach. Please expect/forgive some possible glitches as this isn't my direct area of expertise. Inputs/goals: a) The above re umask behavior. Also the two distinct Posix behaviors of chmod, it either impacting the primary group "permanently", or impacting only the mask. [Q: Are these the only differences between "simple" and "extended ACLs" behavior, as far as actions that create ACLs/make changes go?] b) I note that on Linux it still seems to take explicit user action to end up with "extended ACLs" behavior. At least in my experiences so far, new installs aren't typically set up in such a way that users would see any such cases, unless/until they create such themselves, most likely only via explicit use of setfacl. So I'm interpreting that "extended ACLs" behavior isn't something that Linux is trying to push people into using, it's an available option but not seeming preferred/forced. Build and install scripts for the various packages are likely not expecting "extended ACLs" behavior, and so far it wouldn't seem likely that there'd be a major round of rewriting of them all. Thus I'm thinking it's likely not so desirable that Cygwin would consider existing cases to be ones that get "extended ACLs" behavior. Existing cases would seem better "grandfathered", continuing with closer to existing non-"extended ACLs" behavior re umask and chmod. c) The desire of various folk to have some ACL entries always present for non-Cygwin maintenance/backup programs. And as a subpart of this, a desire by various folk that the 'visible' mode bits (what's seen in ls and by programs checking for 'tight' permissions) would ignore these, even if that means that that these Cygwin programs aren't seeing all the actual permissions granted on the dirs/files. (I suspect here is where contrary opinions might exist. Those more wanting to use Cygwin to manage Windows, rather than as a Posix-compatible environment despite of Windows, would likely prefer that all actual permissions are visible.) d) The desire to have some to-be-inherited/default ACL present on a directory for non-Cygwin programs to be able to create files in it sanely. e) A desire to provide good Posix setfacl behavior as new functionality, but to avoid hassling people who aren't really looking for that functionality, want their current environments to keep working mostly as-is. (Not sure if the upwards compatibility concen is generally as topmost in Cygwi
Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7
On Apr 19 13:50, random user wrote: > >>> I note that chmod doesn't keep these to-be-inherited entries in > sync with the directory's mode; > >>Yep. Did you check against Linux behaviour? > > The difference to my eye is that on Linux there is no such > to-be-inherited CREATOR OWNER ACL entry created implicitly by mkdir. > If there is one existing, it's because it was created explicitly with > setfacl, so seems more the user's responsibility to maintain. Yes, but Linux doesn't have to maintain native Windows tools. I would rather not have these default entries but they are there for ages and they seem to be useful to people. So what's the point? On Linux the "default-default" entries are not changes with chmod, and on Cygwin they aren't either. And that's the right thing to do on both systems. A chmod on a dir never influences the mask of files created in that directory. > >> Any suggestions? Always applying umask, no matter what? > > Please, no. That would create a behavior pattern quite different than > Linux's. I don't myself like some aspects of the Linux/Posix > behavior, but, at least to me, having Cygwin behave compatibly so that > code/scripts behave the same on Cygwin as on Linux is way more > important. (Please read this paragraph also as my reply to you re the > Item 1 topic.) > > Tho, to be precise: I think I am seeing on Linux that umask is always > applied, just it is applied differently depending on whether any > default ACL entries are present on the parent directory: http://linux.die.net/man/5/acl explains it: If a default ACL is associated with a directory, the mode parameter to the functions creating file objects and the default ACL of the directory are used to determine the ACL of the new object: 1. The new object inherits the default ACL of the containing directory as its access ACL. 2. The access ACL entries corresponding to the file permission bits are modified so that they contain no permissions that are not contained in the permissions specified by the mode parameter. If no default ACL is associated with a directory, the mode parameter to the functions creating file objects and the file creation mask (see umask(2)) are used to determine the ACL of the new object: 1. The new object is assigned an access ACL containing entries of tag types ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER. The permissions of these entries are set to the permissions specified by the file cre‐ ation mask. 2. The access ACL entries corresponding to the file permission bits are modified so that they contain no permissions that are not contained in the permissions specified by the mode parameter. Bottom line: Either the parent has default perms, or umask is applied. > As to a suggestion OK, I'll toss out a strawman. Maybe it'll be > food for thought, parts of it useful, even if you don't like/choose > the entire approach. Please expect/forgive some possible glitches as > this isn't my direct area of expertise. > [...] Sorry, but that sounds much too complicated for my taste. Let me simplify this a bit. I'm only concerned about the behaviour of the underlying functions in Cygwin for this, and it should be *simple* so that the logic isn't too confusing and still understood in a year. From the new code's perspective there are two kinds of ACLs, old or native Windows ones, and new ones. Problem: We need those three inheritable ACEs for native tools, When creating a new file, it will inherit these ACEs. On each file creation, Cygwin checks the ACL and pulls it straight again. We would like to allow file creation to recognize the created ACL as being a "standard" ACL and apply umask. For new-style ACLs it looks easy: We could define an extra bit in the inheritable DENY NULL ACE. if the bit is set (after mkdir) Cygwin applies umask for files created within. If not (after setfacl) it doesn't. That leaves the existing, Cygwin-created ACLs. I think we should compromise here. If the incoming, inherited ACL contains the three entries for user, group, and other, it's with very high probability inherited from a Cygwin created directory. If the inherited ACL contains nothing else, we're going to apply umask, otherwise we don't. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpmqDo4Tzlad.pgp Description: PGP signature
Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7
Thanks for the explanation/correction about umask's non-impact if there are default ACL entries. I'm not recalling exactly what I had seen on Linux that made me think there was an impact. >> If the incoming, inherited ACL contains the three entries for user, group, and other, it's with very high probability inherited from a Cygwin created directory. If the inherited ACL contains nothing else, we're going to apply umask, otherwise we don't. Sounds like that'll maintain current behavior reasonably, thanks. >> So what's the point? On Linux the "default-default" entries are not changes with chmod, and on Cygwin they aren't either. And that's the right thing to do on both systems. A chmod on a dir never influences the mask of files created in that directory. I wasn't trying to suggest chmod should change these. It's mkdir I was wondering about, wondering whether it should stop trying to mirror the directory mode into the "default-defaults", just always set as CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(Rc,S,RA) Everyone:(OI)(CI)(IO)(Rc,S,RA) I change my mind on this tho, noticing that if on Linux I have a directory that's mode 550 with no other ACL entries yet existing, and do a "setfacl -m 'd:g:adm:rwx' .", the result also includes new default ACL entries for d:u::r-x and d:g::r-x. If mirroring the directory's own mode is the way the Posix-behaved default ACL entries are to be created, it would seem best that the Cygwin-mkdir-created ones would continue same. But I'm still thinking it'd be goodness if setfacl were to create the same to-be-inherited entries as mkdir does if no other to-be-inherited ACL entries end up present, so setfacl would never leave a directory with no to-be-inherited ACL entries and so lead to troubles should a non-Cygwin program create a file in it. >> Sorry, but that sounds much too complicated for my taste. >> I'm only concerned about the behaviour of the underlying functions in Cygwin for this, and it should be *simple* so that the logic isn't too confusing and still understood in a year. What wasn't about the "default-default" entries was intended to see if you might like a possible alternative idea for dealing with SYSTEM, ADMINISTRATORS, and other administrative/Windows-program-purposed ACL entries. Goal is to no longer have these have impact on the visible mode bits, to deal with the topic of prior complaints as you seem now trying to do for SYSTEM and ADMINISTRATORS, but there do seem remaining desires expressed in recent emails to have other SIDs able to be similarly treated. And now also to prevent these alone from triggering the new "extended ACLs" behavior. The thought is rather than special casing by SID, instead separate (via your new use of DENYs, NULL SID entry, etc.) by whether a particular ACL entry has been created/modified by new-version Cygwin setfacl or not. Entries that have/haven't should be able to coexist in the same ACL, marked by presence/absence of a preceeding DENY. Thus any SID could be used for a non-Posix-purpose/behavior ACL entry, and on the flipside should someone desire they could create a Posix-behavior ACL entry for ADMINISTRATORS. For any ACL entry not created/modified by new-version Cygwin setfacl, other than the ones representing the simple mode permissions, Cygwin would simply choose to 'say' "that's not a Posix-behaved one, I'll neither show it nor change it." What if at the Cygwin library/Posix-API level, the acl_*() functions (or I guess their Solaris equivalents in current Cygwin coding) would simply not include these at all? And similarly the permission mode bits would simply not include any impact from these, chmod would never change these? And the rights they provide would be implicitly visible in other APIs only exactly as Linux reflects effects of root's magic rights? The inside-the-library code that reads Windows ACLs would have to filter to simply ignore these entries, the code that writes Windows ACLs would have to merge/retain these entries as-is (possibly removing one if a Posix-behaved entry for same SID were created, that seems a choice you could make either way); might most everything else then just fall out properly? -- 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
