* Issues with ACL settings after updating to the latest cygwin.dll @ 2016-01-30 20:46 K Stahl 2016-02-08 14:16 ` Corinna Vinschen 0 siblings, 1 reply; 15+ messages in thread From: K Stahl @ 2016-01-30 20:46 UTC (permalink / raw) To: cygwin I've discovered that when I use cvs to pull a module, the security settings on the created files and directories are incorrect. When I view the security settings of the files, I noticed an invalid "NULL SID" group permission was added. If I delete this value, I can properly execute the file, but if I leave it there, the file I'm trying to execute will not run. NOTE: If I use wincvs, the files are fine. This only happens within the cygwin environment. -- 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] 15+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll 2016-01-30 20:46 Issues with ACL settings after updating to the latest cygwin.dll K Stahl @ 2016-02-08 14:16 ` Corinna Vinschen 2016-02-08 17:48 ` Re[2]: " xnor 0 siblings, 1 reply; 15+ messages in thread From: Corinna Vinschen @ 2016-02-08 14:16 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1049 bytes --] On Jan 29 17:52, K Stahl wrote: > I've discovered that when I use cvs to pull a module, the security > settings on the created files and directories are incorrect. When I > view the security settings of the files, I noticed an invalid "NULL > SID" group permission was added. If I delete this value, I can > properly execute the file, but if I leave it there, the file I'm > trying to execute will not run. I'm not quite sure what you observe there. The NULL SID ACE only contains extra information about some POSIX bits and the MASK value. It's existence and setting should not influence what you can do with the file. The permission bits are explicitely set elsewhere in the ACL. Can you reproduce the issue so that I can see what's going on? I need the icacls output for the file and its parent directory, as well as the output from getfacl for both. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re[2]: Issues with ACL settings after updating to the latest cygwin.dll 2016-02-08 14:16 ` Corinna Vinschen @ 2016-02-08 17:48 ` xnor 2016-02-08 18:12 ` Re[3]: " xnor ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: xnor @ 2016-02-08 17:48 UTC (permalink / raw) To: cygwin >I'm not quite sure what you observe there. The NULL SID ACE only >contains extra information about some POSIX bits and the MASK value. >It's existence and setting should not influence what you can do with >the >file. The permission bits are explicitely set elsewhere in the ACL. > >Can you reproduce the issue so that I can see what's going on? I need >the icacls output for the file and its parent directory, as well as the >output from getfacl for both. I have the same problem with Transmission. I noticed this first when I tried to execute an exe that was downloaded with Transmission compiled in cygwin. When trying to start the exe from Explorer an error dialog will appear: "Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item." When going to file properties - security I get an information dialog window: "The permissions on <program> are incorrectly ordered, which may cause some entries to be ineffective." Proper permissions (of parent folder) look like this: Authenticated Users: modify SYSTEM: Full control Administrators: Full control Users: Read & execute The permissions of the cygwin/transmission created files are (manually translated from German): NULL SID: special <My User>: special Authenticated Users: Browse folder / Execute file SYSTEM: Browse folder / Execute file Administrators: Browse folder / Execute file Users: Browse folder / Execute file Nobody: Read Authenticated Users: Read, write, execute SYSTEM: Read, write, execute Administrators: Read, write, execute Users: Read, Execute Everyone: Read Also when going to advanced permissions it shows the same incorrectly ordered warning and asks me to re-order permissions. -- 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] 15+ messages in thread
* Re[3]: Issues with ACL settings after updating to the latest cygwin.dll 2016-02-08 17:48 ` Re[2]: " xnor @ 2016-02-08 18:12 ` xnor 2016-02-08 18:22 ` Corinna Vinschen 2016-02-08 18:20 ` Corinna Vinschen 2016-02-08 18:33 ` Re[3]: " xnor 2 siblings, 1 reply; 15+ messages in thread From: xnor @ 2016-02-08 18:12 UTC (permalink / raw) To: cygwin >Nobody: Read Small correction, this entry is actually S-1-5-21-559282050-488988736-2019639472-513 which actually stalls the file properties window when switching to the security tab for a while. I guess Windows is trying to resolve this SID but gives up (there is no such SID on my system) and eventually replaces the display name with Nobody. Something is seriously broken here. -- 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] 15+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll 2016-02-08 18:12 ` Re[3]: " xnor @ 2016-02-08 18:22 ` Corinna Vinschen 0 siblings, 0 replies; 15+ messages in thread From: Corinna Vinschen @ 2016-02-08 18:22 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 915 bytes --] On Feb 8 18:12, xnor wrote: > > >Nobody: Read > Small correction, this entry is actually > S-1-5-21-559282050-488988736-2019639472-513 > > which actually stalls the file properties window when switching to the > security tab for a while. I guess Windows is trying to resolve this SID but > gives up (there is no such SID on my system) and eventually replaces the > display name with Nobody. No idea why this is stalling your machine, but the above group SID always exists on all machines and is perfectly valid (SID == machine SID + RID 513). It's the primary group of all local (non-AD) user accounts, and it's called "None" in English, with a localized name in other locales. > Something is seriously broken here. Not that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll 2016-02-08 17:48 ` Re[2]: " xnor 2016-02-08 18:12 ` Re[3]: " xnor @ 2016-02-08 18:20 ` Corinna Vinschen 2016-02-09 20:53 ` Re[2]: " xnor 2016-02-08 18:33 ` Re[3]: " xnor 2 siblings, 1 reply; 15+ messages in thread From: Corinna Vinschen @ 2016-02-08 18:20 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2633 bytes --] On Feb 8 17:48, xnor wrote: > > >I'm not quite sure what you observe there. The NULL SID ACE only > >contains extra information about some POSIX bits and the MASK value. > >It's existence and setting should not influence what you can do with the > >file. The permission bits are explicitely set elsewhere in the ACL. > > > >Can you reproduce the issue so that I can see what's going on? I need > >the icacls output for the file and its parent directory, as well as the > >output from getfacl for both. > I have the same problem with Transmission. > > I noticed this first when I tried to execute an exe that was downloaded with > Transmission compiled in cygwin. When trying to start the exe from Explorer > an error dialog will appear: > "Windows cannot access the specified device, path, or file. You may not have > the appropriate permissions to access the item." Not sure what Transmission is, but files downloaded with POSIX tools are usually not executable. For instance, download Cygwin's setup-x86.exe with wget. Then try to execute it. It won't since the permissions are set according to your umask and without execute permissions, e.g., 0644. This is normal. > When going to file properties - security I get an information dialog window: > "The permissions on <program> are incorrectly ordered, which may cause some > entries to be ineffective." > > Proper permissions (of parent folder) look like this: > Authenticated Users: modify > SYSTEM: Full control > Administrators: Full control > Users: Read & execute > > > The permissions of the cygwin/transmission created files are (manually > translated from German): > NULL SID: special > <My User>: special > Authenticated Users: Browse folder / Execute file > SYSTEM: Browse folder / Execute file > Administrators: Browse folder / Execute file > Users: Browse folder / Execute file > Nobody: Read > Authenticated Users: Read, write, execute > SYSTEM: Read, write, execute > Administrators: Read, write, execute > Users: Read, Execute > Everyone: Read > > > Also when going to advanced permissions it shows the same incorrectly > ordered warning and asks me to re-order permissions. The permissions must *not* be reordered. If Cygwin creates permissions incorrectly it's one thing, but the order to emulate POSIX permissions is non-canonical. Reordering them will break them. Please provide the exact output from icacls. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re[2]: Issues with ACL settings after updating to the latest cygwin.dll 2016-02-08 18:20 ` Corinna Vinschen @ 2016-02-09 20:53 ` xnor 2016-02-10 2:20 ` Andrey Repin 2016-02-10 11:55 ` Corinna Vinschen 0 siblings, 2 replies; 15+ messages in thread From: xnor @ 2016-02-09 20:53 UTC (permalink / raw) To: cygwin >Not sure what Transmission is, but files downloaded with POSIX >tools are usually not executable. For instance, download Cygwin's >setup-x86.exe with wget. Then try to execute it. It won't since >the permissions are set according to your umask and without execute >permissions, e.g., 0644. This is normal. The behavior has changed with the ACL change in Cygwin and I would not consider that "normal". The warning from Windows is not normal. I realize that the previous implementation was already problematic and messed with permissions but I did not notice it since it never denied executing executables. >The permissions must *not* be reordered. If Cygwin creates permissions >incorrectly it's one thing, but the order to emulate POSIX permissions >is non-canonical. Reordering them will break them. > >Please provide the exact output from icacls. They *have* to be reordered to be modifiable in Windows/Explorer. In other words, if I want to change permission the new ACL behavior ensures that it breaks the Cygwin permissions? Here is the output from icacls /saveacl for some file: D:P(D;;RPWPDTRC;;;S-1-0-0)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD) After letting Windows fix the order: D:PAI(D;;RPWPDTRC;;;S-1-0-0)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD) Here is what's "normal" for Windows if I create a file under a new folder on C: in Explorer: D:AI(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU) Strangely enough this is displayed as "-rwxrwx---+ MyUser None" with `ls -l` even though my user is in the group Administrators. Here is what I would expect: MyUser is in the group Administrators. Given the inherited permissions above a Windows-created file should be shown as "-rwxrwxr--+ MyUser Administrators"? After chmod 664 I would expect this: - still inherit all the permissions - add permission MyUser DENY execute - add permission Administrators DENY execute - add permission Everyone ALLOW read Instead Cygwin copies all permissions, drops the inheritance, copies them again, adds None, adds NULL SID ... After a consecutive chmod 770 I would expect the above non-inherited permissions to be removed again. -- 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] 15+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll 2016-02-09 20:53 ` Re[2]: " xnor @ 2016-02-10 2:20 ` Andrey Repin 2016-02-10 17:39 ` Re[2]: " xnor 2016-02-10 11:55 ` Corinna Vinschen 1 sibling, 1 reply; 15+ messages in thread From: Andrey Repin @ 2016-02-10 2:20 UTC (permalink / raw) To: xnor, cygwin Greetings, xnor! >>The permissions must *not* be reordered. If Cygwin creates permissions >>incorrectly it's one thing, but the order to emulate POSIX permissions >>is non-canonical. Reordering them will break them. >> >>Please provide the exact output from icacls. > They *have* to be reordered to be modifiable in Windows/Explorer. In > other words, if I want to change permission the new ACL behavior ensures > that it breaks the Cygwin permissions? It was always the case. Permissions are NOT REQUIRED to be ordered in a specific way, but Explorer is only capable of editing them in the only one way. Means, Explorer is deficient. Explorer. Not Windows. Windows is perfectly capable of handling the Cygwin ACL in the intended way. -- With best regards, Andrey Repin Wednesday, February 10, 2016 05:05:14 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re[2]: Issues with ACL settings after updating to the latest cygwin.dll 2016-02-10 2:20 ` Andrey Repin @ 2016-02-10 17:39 ` xnor 2016-02-10 18:35 ` Andrey Repin 0 siblings, 1 reply; 15+ messages in thread From: xnor @ 2016-02-10 17:39 UTC (permalink / raw) To: cygwin >It was always the case. >Permissions are NOT REQUIRED to be ordered in a specific way, but >Explorer is >only capable of editing them in the only one way. >Means, Explorer is deficient. Explorer. Not Windows. Windows is >perfectly >capable of handling the Cygwin ACL in the intended way. No, it really wasn't. The ACLs were fine until the change in the new Cygwin version. Now there are 12 ACL entries, all non inherited / inheritance is broken, for each file... Also, I always ways able to change ACLs through Explorer without warnings, which I need to do from time to time. I'm sorry but all of this can be summed up as bad design. I've explained what ACLs should be added by Cygwin in a related message. By making use of default, inherited ACLs, at most 3 (+1 for whatever NULL SID is doing ...) are needed. At least I see no reason why there should be such a bloat. Besides, if cygwin set ACLs properly on the root folder this could be reduced to 0 additional non-inherited ACLs for many files. -- 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] 15+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll 2016-02-10 17:39 ` Re[2]: " xnor @ 2016-02-10 18:35 ` Andrey Repin 0 siblings, 0 replies; 15+ messages in thread From: Andrey Repin @ 2016-02-10 18:35 UTC (permalink / raw) To: xnor, cygwin Greetings, xnor! >>It was always the case. >>Permissions are NOT REQUIRED to be ordered in a specific way, but >>Explorer is >>only capable of editing them in the only one way. >>Means, Explorer is deficient. Explorer. Not Windows. Windows is >>perfectly >>capable of handling the Cygwin ACL in the intended way. > No, it really wasn't. > The ACLs were fine until the change in the new Cygwin version. Now there > are 12 ACL entries, all non inherited / inheritance is broken, for each > file... That's normal POSIX behavior. If you want Windows behavior, mount your outside-Cygwin FS with noacl flag. -- With best regards, Andrey Repin Wednesday, February 10, 2016 21:20:45 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll 2016-02-09 20:53 ` Re[2]: " xnor 2016-02-10 2:20 ` Andrey Repin @ 2016-02-10 11:55 ` Corinna Vinschen 2016-02-10 12:19 ` Corinna Vinschen 1 sibling, 1 reply; 15+ messages in thread From: Corinna Vinschen @ 2016-02-10 11:55 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 4304 bytes --] On Feb 9 20:53, xnor wrote: > > >Not sure what Transmission is, but files downloaded with POSIX > >tools are usually not executable. For instance, download Cygwin's > >setup-x86.exe with wget. Then try to execute it. It won't since > >the permissions are set according to your umask and without execute > >permissions, e.g., 0644. This is normal. > The behavior has changed with the ACL change in Cygwin and I would not > consider that "normal". The warning from Windows is not normal. Which warning do you mean here? > I realize that the previous implementation was already problematic and > messed with permissions but I did not notice it since it never denied > executing executables. No, but either way, the created ACL is not necessarily what Microsoft describes as "canonical". POSIX permissions just don't map well with canonical-only ACLs. The problem right now is that I can't reproduce what you encounter. That's why I'm asking for the details in terms of the ACL, that is, output from icacls and getfacl to compare the output and ideally being able to reproduce and, even more ideal, fix it. Come on, be fair. The new ACL handling started out early 2015, got a break when I realized that it doesn't work as is, and then got a new test phase starting back in September. Except for minor bugs it seemed to work rather well. Nobody reported this effect in all the 4 months of test period. You don't actually think I wouldn't have fixed it prior to the release if I had known about it, do you? > >The permissions must *not* be reordered. If Cygwin creates permissions > >incorrectly it's one thing, but the order to emulate POSIX permissions > >is non-canonical. Reordering them will break them. > > > >Please provide the exact output from icacls. > They *have* to be reordered to be modifiable in Windows/Explorer. In other > words, if I want to change permission the new ACL behavior ensures that it > breaks the Cygwin permissions? They are not supposed to be modifiable in Explorer. If you want to change permissions on a Cygwin ACL, use chmod or setfacl. > Here is the output from icacls /saveacl for some file: > D:P(D;;RPWPDTRC;;;S-1-0-0)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD) Doh, I'm sorry, but I can't read this format very well. Can you please again send the standard icacls output as well as the output from getfacl of the parent dir and the created file? I'd like to have this problem fixed, but I need your help. As I said, it works fine for me and without being able to reproduce I'm somewhat at a loss. > Here is what's "normal" for Windows if I create a file under a new folder on > C: in Explorer: If you don't want POSIX perms, but standard Windows perms, use the "noacl" mount option. See https://cygwin.com/cygwin-ug-net/using.html#mount-table > Here is what I would expect: > MyUser is in the group Administrators. Given the inherited permissions above > a Windows-created file should be shown as "-rwxrwxr--+ MyUser > Administrators"? Sorry, can't do that, *unless* you make "Administrators" the primary group in your user token(*). Even though your account is *member* of the Administrators group, the group is *never* your primary group per Windows. All local accounts, independently of their group memberships, have the group "None" as their primary group. That's how Windows works, and that hasn't changed since at least NT4. Unless, of course, if you use a so-called "Windows account", one of those accounts which you login with using your email address (was that introduced with Windows 8? I'm not sure). In that case, the primary group in your user token is set to your user account itself. So your primary group SID is your own user SID. Duh! Corinna (*) There *is* a way to do that, but only inside Cygwin, see https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-passwdinfo -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll 2016-02-10 11:55 ` Corinna Vinschen @ 2016-02-10 12:19 ` Corinna Vinschen 0 siblings, 0 replies; 15+ messages in thread From: Corinna Vinschen @ 2016-02-10 12:19 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 3222 bytes --] On Feb 10 12:55, Corinna Vinschen wrote: > On Feb 9 20:53, xnor wrote: > > Here is what I would expect: > > MyUser is in the group Administrators. Given the inherited permissions above > > a Windows-created file should be shown as "-rwxrwxr--+ MyUser > > Administrators"? > > Sorry, can't do that, *unless* you make "Administrators" the primary > group in your user token(*). Even though your account is *member* of > the Administrators group, the group is *never* your primary group per > Windows. All local accounts, independently of their group memberships, > have the group "None" as their primary group. That's how Windows works, > and that hasn't changed since at least NT4. > > Unless, of course, if you use a so-called "Windows account", one of > those accounts which you login with using your email address (was that > introduced with Windows 8? I'm not sure). In that case, the primary > group in your user token is set to your user account itself. So your > primary group SID is your own user SID. Duh! > > > Corinna > > (*) There *is* a way to do that, but only inside Cygwin, see > https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-passwdinfo Oh, and if it's not clear how this works under the hood, it's like this: The Windows user token contains a couple of SID entries: - The "user" SID - The "owner" SID (user and owner are not necessarily the same, but, never mind) - The primary group SID (which, it has to be said, is meaningless in the Windows context and only kept for POSIX compatibility) - A list of group SIDs the user is member in. For a local account, the primary group SID is set to "None", the local group with RID 513. For domain accounts this is typically the group "Domain Users", the domain account with RID 513 (hmm...) However, every process is allowed to switch the primary group entry of its user token to *any* group mentioned in the group list, *or* even to its user or owner SID. If you use the aforementioned method to change the primary group, what happens is that the first Cygwin process in a process chain changes the primary group in its user token. If the new group is in the token's group list, this will work. Child processes inherit the user token from their parent process, so there's no reason to change the primary group again in a process tree. Since that's a Windows property, this also works for non-Cygwin child processes. With the Administrators group there's a complication. If you're running a normal shell, it's running under UAC control. UAC restricts the user token of an admin user so that the admins group in the token group list is "crippled": The admins SID is still in the list, but with a flag "DENY ONLY". You're kind of not in the Administrators group anymore. Only if an access check is performed, and the Admins group is denied access to some object, this membership kicks in and denies the access. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re[3]: Issues with ACL settings after updating to the latest cygwin.dll 2016-02-08 17:48 ` Re[2]: " xnor 2016-02-08 18:12 ` Re[3]: " xnor 2016-02-08 18:20 ` Corinna Vinschen @ 2016-02-08 18:33 ` xnor 2016-02-09 15:02 ` K Stahl 2 siblings, 1 reply; 15+ messages in thread From: xnor @ 2016-02-08 18:33 UTC (permalink / raw) To: cygwin >I have the same problem with Transmission. Sorry for another mail, but I need to make another last correction: It's not Transmission specific. A simple $ cd /cygdrive/path/to/download/dir $ touch test will result in the same broken permissions for test. Doing this in $HOME will result in these Windows permissions: NULL SID Everyone <My User> Nobody (actually non existent S-1-5-21-...) There are also no warnings and no prompt to re-order permissions. File permission for an older file (created before cygwin ACL changes): Everyone <My User> Nobody (actually non existent S-1-5-21-...) So the new ACL implementation simply messes up in directories with non-cygwin permissions. -- 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] 15+ messages in thread
* Re: Re[3]: Issues with ACL settings after updating to the latest cygwin.dll 2016-02-08 18:33 ` Re[3]: " xnor @ 2016-02-09 15:02 ` K Stahl 2016-02-10 11:56 ` Corinna Vinschen 0 siblings, 1 reply; 15+ messages in thread From: K Stahl @ 2016-02-09 15:02 UTC (permalink / raw) To: cygwin, xnor On Feb 8, 2016 1:33 PM, "xnor" <xnoreq@gmail.com> wrote: > > >> I have the same problem with Transmission. > > Sorry for another mail, but I need to make another last correction: > It's not Transmission specific. A simple > $ cd /cygdrive/path/to/download/dir > $ touch test > will result in the same broken permissions for test. > > Doing this in $HOME will result in these Windows permissions: > NULL SID > Everyone > <My User> > Nobody (actually non existent S-1-5-21-...) > > There are also no warnings and no prompt to re-order permissions. > > > File permission for an older file (created before cygwin ACL changes): > Everyone > <My User> > Nobody (actually non existent S-1-5-21-...) > > > So the new ACL implementation simply messes up in directories with non-cygwin permissions. > > > > -- > 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 > Thanks xnor for documenting the issue! I've been on travel and didn't have access to my cygwin installation. In my case, I have to use CVS to download source code and executables. Once a file is downloaded, the permissions are set. Each file created using the new ACL features has the NUL SID set and this in turn in fine for regular files, but those that have an execution bit set will not run unless I open their properties in Wnidows, change the security permissions (which states there is a error). -- 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] 15+ messages in thread
* Re: Re[3]: Issues with ACL settings after updating to the latest cygwin.dll 2016-02-09 15:02 ` K Stahl @ 2016-02-10 11:56 ` Corinna Vinschen 0 siblings, 0 replies; 15+ messages in thread From: Corinna Vinschen @ 2016-02-10 11:56 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1921 bytes --] On Feb 9 10:01, K Stahl wrote: > On Feb 8, 2016 1:33 PM, "xnor" <xnoreq@gmail.com> wrote: > > > > > >> I have the same problem with Transmission. > > > > Sorry for another mail, but I need to make another last correction: > > It's not Transmission specific. A simple > > $ cd /cygdrive/path/to/download/dir > > $ touch test > > will result in the same broken permissions for test. > > > > Doing this in $HOME will result in these Windows permissions: > > NULL SID > > Everyone > > <My User> > > Nobody (actually non existent S-1-5-21-...) > > > > There are also no warnings and no prompt to re-order permissions. > > > > > > File permission for an older file (created before cygwin ACL changes): > > Everyone > > <My User> > > Nobody (actually non existent S-1-5-21-...) > > > > > > So the new ACL implementation simply messes up in directories with non-cygwin permissions. > > > > > > > > -- > > 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 > > > > Thanks xnor for documenting the issue! I've been on travel and didn't > have access to my cygwin installation. > > In my case, I have to use CVS to download source code and executables. > Once a file is downloaded, the permissions are set. Each file created > using the new ACL features has the NUL SID set and this in turn in > fine for regular files, but those that have an execution bit set will > not run unless I open their properties in Wnidows, change the security > permissions (which states there is a error). https://cygwin.com/ml/cygwin/2016-02/msg00077.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-02-10 18:35 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-30 20:46 Issues with ACL settings after updating to the latest cygwin.dll K Stahl 2016-02-08 14:16 ` Corinna Vinschen 2016-02-08 17:48 ` Re[2]: " xnor 2016-02-08 18:12 ` Re[3]: " xnor 2016-02-08 18:22 ` Corinna Vinschen 2016-02-08 18:20 ` Corinna Vinschen 2016-02-09 20:53 ` Re[2]: " xnor 2016-02-10 2:20 ` Andrey Repin 2016-02-10 17:39 ` Re[2]: " xnor 2016-02-10 18:35 ` Andrey Repin 2016-02-10 11:55 ` Corinna Vinschen 2016-02-10 12:19 ` Corinna Vinschen 2016-02-08 18:33 ` Re[3]: " xnor 2016-02-09 15:02 ` K Stahl 2016-02-10 11:56 ` Corinna Vinschen
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).