* POSIX permission mapping and NULL SIDs @ 2016-06-24 19:02 Bill Zissimopoulos 2016-06-24 21:37 ` Corinna Vinschen 0 siblings, 1 reply; 23+ messages in thread From: Bill Zissimopoulos @ 2016-06-24 19:02 UTC (permalink / raw) To: cygwin EXEUTIVE EDITION I am seeking information on how exactly Cygwin uses NULL SID ACE’s in Windows ACL’s. Cygwin’s use of NULL SID ACE’s interferes with my use of the NULL SID to represent “nobody”/“nogroup”. AN EXPERIMENT Working through some remaining warts in my WinFsp-FUSE for Cygwin layer I stumbled upon an interesting one last night. In one Cygwin window I ran sshfs -d -o idmap=user XXXX@XXXX Y: Then in another: billziss@windows:~$ cd /cygdrive/y billziss@windows:/cygdrive/y$ ls -la total 8 drwxr-xr-t 1 billziss Unknown+Group 0 Jun 23 23:57 . dr-xr-xr-x 1 billziss None 0 Jun 24 10:13 .. -rw-r--r-T 1 billziss Unknown+Group 15 Jun 23 23:57 Foo.txt What are those sticky bits doing there?! billziss@windows:/cygdrive/y$ cacls Foo.txt /S Y:\Foo.txt "D:P(A;;0x1f019f;;;S-1-5-21-XXXX-1001)(A;;FR;;;S-1-0-0)(A;;FR;;;WD)" Ok, so WinFsp-FUSE presents an ACL with the proper rights for the owner (billziss), read rights for the NULL SID and read rights for the WORLD SID. We see the NULL SID because WinFsp-FUSE maps unknown users to it (nobody/nogroup). This looks correct. How does Cygwin decide that the sticky bit is somehow set?! PERMISSION MAPPING IN WINFSP-FUSE WinFsp-FUSE implements permissions as described in the "Permissions In Microsoft Services for UNIX v3.0” [PERMS]. This document contains a discussion of mapping the sticky and setuid/setgid bits. They use combinations of the FILE_DELETE_CHILD access right to implement the sticky bit and NTFS extended attributes to implement the setuid/setgid bits. WinFsp-FUSE follows the same methodology for the sticky bit and ignores the setuid/setgid bits. WinFsp-FUSE also has a UID/SID mapping that is (mostly) compatible with Cygwin’s. I do not implement the trustPosixOffset, because I am lazy and because I do not understand it. Turns out that there is another incompatibility: I map unknown UID’s to the NULL SID (S-1-0-0). Could my mapping of the NULL SID somehow interfere with Cygwin’s ACL mapping? No way right? Turns out that: yes! File:winsup/cygwin/sec_acl.cc, line:787 if (ace_sid == well_known_null_sid) { /* Fetch special bits. */ attr |= CYG_ACE_ISBITS_TO_POSIX (ace->Mask); if (ace->Header.AceType == ACCESS_DENIED_ACE_TYPE && ace->Mask & CYG_ACE_NEW_STYLE) { /* New-style ACL. Note the fact that a mask value is present since that changes how getace fetches the information. That's fine, because the NULL deny ACE is supposed to precede all USER, GROUP and GROUP_OBJ entries. Any ACL not created that way has been rearranged by the Windows functionality to create the brain-dead "canonical" ACL order and is broken anyway. */ new_style = true; attr |= CYG_ACE_ISBITS_TO_POSIX (ace->Mask); So Cygwin appears to use NULL SID ACE’s to store the special bits. In addition if the ACE is a special ACCESS_DENIED one it assigns even more semantics to it. Allow me to say that I find this a *gross* hack. You are subverting the Windows ACL mechanism to store information that it was not designed to store. I would love to hear a good rationale for this decision. BTW, this also appears to break BashOnWindows: see [BASHW] In any case I am seeking more information regarding Cygwin’s use of NULL SID’s. I have found an old post that sheds some light [OPOST]. I am also seeking an alternative to using the NULL SID for “nobody”/“nogroup”. Is there a Cygwin suggested one? Bill [PERMS] https://technet.microsoft.com/en-us/library/bb463216.aspx [BASHW] https://github.com/Microsoft/BashOnWindows/issues/51 [OPOST] https://www.cygwin.com/ml/cygwin/2015-02/msg00197.html ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-24 19:02 POSIX permission mapping and NULL SIDs Bill Zissimopoulos @ 2016-06-24 21:37 ` Corinna Vinschen 2016-06-24 22:00 ` Corinna Vinschen 2016-06-24 22:06 ` Bill Zissimopoulos 0 siblings, 2 replies; 23+ messages in thread From: Corinna Vinschen @ 2016-06-24 21:37 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2691 bytes --] On Jun 24 18:07, Bill Zissimopoulos wrote: > Could my mapping of the NULL SID somehow interfere with Cygwin’s ACL > mapping? No way right? Turns out that: yes! File:winsup/cygwin/sec_acl.cc, > line:787 Read the comment at the beginning of the file explaining how new-style ACLs look like. > Allow me to say that I find this a *gross* hack. You are subverting the > Windows ACL mechanism to store information that it was not designed to > store. I would love to hear a good rationale for this decision. The usage of NULL SID ACEs to store special POSIX permission bits is long-standing behaviour, first implemented by U/Win and later adopted by Cygwin. That older version is using Access-allowed NULL SID ACEs for *ages* to store ISVTX, ISGID and ISUID bits. The new implementation uses access-denied NULL SID ACEs to store the same bits, plus the POSIX MASK bits. Another access-denied NULL SID ACEs with the "Inherit Only" bit set is used to specify the same info for the POSIX default ACL. > BTW, this also appears to break BashOnWindows: see [BASHW] I'm not overly sympathetic. Cygwin's implementation is older. If Microsoft provides full support for POSIX permission bits plus POSIX ACLs including useful documentation, I'm willing to reconsider. And matching patches are welcome of course. What strikes me as weird is that nobody from the UoW side is trying to work with Cygwin ACLs or even trying to communicate with us to define and implement POSIX ACLs in a documented, generic way for both systems. > In any case I am seeking more information regarding Cygwin’s use of NULL > SID’s. I have found an old post that sheds some light [OPOST]. That's old. See the comment at the beginning of sec_acl.cc, as well as the comments in set_posix_access() in the same file. > I am also seeking an alternative to using the NULL SID for > “nobody”/“nogroup”. Is there a Cygwin suggested one? Not yet. We're coming from the other side. We always have *some* SID. pwdgrp::fetch_account_from_windows() in uinfo.cc tries to convert the SID to a passwd or group entry. If everything fails, the SID is used in this passwd/group entry verbatim, but mapped to uid/gid -1. If you want some specific mapping we can arrange that, but it must not be the NULL SID. If you know you're communicating with a Cygwin process, what about using an arbitrary, unused SID like S-1-0-42? How do you differ nobody from nogroup if you use the same SID for both, btw.? 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] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-24 21:37 ` Corinna Vinschen @ 2016-06-24 22:00 ` Corinna Vinschen 2016-06-24 22:06 ` Bill Zissimopoulos 1 sibling, 0 replies; 23+ messages in thread From: Corinna Vinschen @ 2016-06-24 22:00 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1896 bytes --] On Jun 24 21:51, Corinna Vinschen wrote: > On Jun 24 18:07, Bill Zissimopoulos wrote: > > Could my mapping of the NULL SID somehow interfere with Cygwin’s ACL > > mapping? No way right? Turns out that: yes! File:winsup/cygwin/sec_acl.cc, > > line:787 > > Read the comment at the beginning of the file explaining how new-style > ACLs look like. > > > Allow me to say that I find this a *gross* hack. You are subverting the > > Windows ACL mechanism to store information that it was not designed to > > store. I would love to hear a good rationale for this decision. > > The usage of NULL SID ACEs to store special POSIX permission bits is > long-standing behaviour, first implemented by U/Win and later adopted by > Cygwin. That older version is using Access-allowed NULL SID ACEs for > *ages* to store ISVTX, ISGID and ISUID bits. The new implementation > uses access-denied NULL SID ACEs to store the same bits, plus the POSIX > MASK bits. Another access-denied NULL SID ACEs with the "Inherit Only" > bit set is used to specify the same info for the POSIX default ACL. > > > BTW, this also appears to break BashOnWindows: see [BASHW] > > I'm not overly sympathetic. Cygwin's implementation is older. If > Microsoft provides full support for POSIX permission bits plus POSIX > ACLs including useful documentation, I'm willing to reconsider. And > matching patches are welcome of course. > > What strikes me as weird is that nobody from the UoW side is trying > to work with Cygwin ACLs or even trying to communicate with us to > define and implement POSIX ACLs in a documented, generic way for both > systems. And why on earth does an access-denied NULL SID ACE affect SoW *at all*? 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] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-24 21:37 ` Corinna Vinschen 2016-06-24 22:00 ` Corinna Vinschen @ 2016-06-24 22:06 ` Bill Zissimopoulos 2016-06-24 22:31 ` Corinna Vinschen 1 sibling, 1 reply; 23+ messages in thread From: Bill Zissimopoulos @ 2016-06-24 22:06 UTC (permalink / raw) To: cygwin On 6/24/16, 12:51 PM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf of corinna-cygwin@cygwin.com> wrote: >>Could my mapping of the NULL SID somehow interfere with Cygwin’s ACL >> mapping? No way right? Turns out that: yes! >>File:winsup/cygwin/sec_acl.cc, >> line:787 > >Read the comment at the beginning of the file explaining how new-style >ACLs look like. Thank you for the pointers and the historical information. >>I am also seeking an alternative to using the NULL SID for >> “nobody”/“nogroup”. Is there a Cygwin suggested one? > >Not yet. We're coming from the other side. We always have *some* SID. >pwdgrp::fetch_account_from_windows() in uinfo.cc tries to convert the SID >to a passwd or group entry. If everything fails, the SID is used in this >passwd/group entry verbatim, but mapped to uid/gid -1. I also noticed that there is no uid mapping for nobody. On my OSX box it is -2. On many other POSIX systems it appears to be the 32-bit or 16-bit equivalent of -2. For the time being I am mapping unknown SID’s to -1 as per Cygwin. >If you want some specific mapping we can arrange that, but it must not >be the NULL SID. If you know you're communicating with a Cygwin process, >what about using an arbitrary, unused SID like S-1-0-42? I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is a bad choice for some reason or other. The main reason that I am weary of using an unused SID is that Microsoft may decide to assign some special powers to it in a future release (e.g. GodMode SID). But I agree that this is rather unlikely in the S-1-0-X namespace. >How do you differ nobody from nogroup if you use the same SID for both, >btw.? I use the same SID for both nobody and nogroup. This should work as long as you use the permission mapping from the [PERMS] document. Bill ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-24 22:06 ` Bill Zissimopoulos @ 2016-06-24 22:31 ` Corinna Vinschen 2016-06-24 22:36 ` Erik Soderquist ` (3 more replies) 0 siblings, 4 replies; 23+ messages in thread From: Corinna Vinschen @ 2016-06-24 22:31 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 3282 bytes --] On Jun 24 21:37, Bill Zissimopoulos wrote: > On 6/24/16, 12:51 PM, "Corinna Vinschen" <cygwin-owner@cygwin.com on > behalf of corinna-cygwin@cygwin.com> wrote: > >Not yet. We're coming from the other side. We always have *some* SID. > >pwdgrp::fetch_account_from_windows() in uinfo.cc tries to convert the SID > >to a passwd or group entry. If everything fails, the SID is used in this > >passwd/group entry verbatim, but mapped to uid/gid -1. > > I also noticed that there is no uid mapping for nobody. On my OSX box it > is -2. On many other POSIX systems it appears to be the 32-bit or 16-bit > equivalent of -2. In fact it's an entirely arbitrary choice. On Fedora Linux, for instance, there is no "nogroup", but there is: /etc/passwd: nobody:x:99:99:Nobody:/:/sbin/nologin nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin /etc/group: nobody:x:99: nfsnobody:x:65534: Note the 65534 here. This is -2 *if* the remote system uses 16 bit signed uid/gid values. However, these days uid/gid values are at least 32 bit, so -2 kind of lost its meaning. > For the time being I am mapping unknown SID’s to -1 as per Cygwin. We could kick this around a bit and maybe reserve -2, 99 or 65534 for an arbitrary "nobody" account. But since we're on Windows the SID value is important, not so much the uid/gid values. > >If you want some specific mapping we can arrange that, but it must not > >be the NULL SID. If you know you're communicating with a Cygwin process, > >what about using an arbitrary, unused SID like S-1-0-42? > > I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is a > bad choice for some reason or other. I thought about Anonymous myself when I wrote my reply to your OP. I refrained from mentioning it because it might have some unexpected side effect we're not aware about. > The main reason that I am weary of using an unused SID is that Microsoft > may decide to assign some special powers to it in a future release (e.g. > GodMode SID). But I agree that this is rather unlikely in the S-1-0-X > namespace. I think it's very unlikely. We could chose any RID value we like and the chance for collision is nil. When I created the new implementation for POSIX ACLs, I toyed around with this already and used a special Cygwin SID within the NULL SID AUTHORITY. I'm not entirely sure why I changed this to the NULL SID deny ACE. I think I disliked the fact that almost every Cygwin ACL would contain a mysterious "unknown SID". On second thought, maybe that would have avoided the UoW problem?!? Well, how should I have known about UoW when I implemanted this, right? > >How do you differ nobody from nogroup if you use the same SID for both, > >btw.? > > I use the same SID for both nobody and nogroup. This should work as long > as you use the permission mapping from the [PERMS] document. Keep in mind that Interix only supported standard POSIX permission bits. Cygwin strives to support POSIX ACLs per POSIX 1003.1e draft 17. That's a bit more extensive. 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] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-24 22:31 ` Corinna Vinschen @ 2016-06-24 22:36 ` Erik Soderquist 2016-06-24 23:03 ` Bill Zissimopoulos 2016-06-24 22:53 ` Bill Zissimopoulos ` (2 subsequent siblings) 3 siblings, 1 reply; 23+ messages in thread From: Erik Soderquist @ 2016-06-24 22:36 UTC (permalink / raw) To: cygwin On Fri, Jun 24, 2016 at 5:59 PM, Corinna Vinschen wrote: >> I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is a >> bad choice for some reason or other. > > I thought about Anonymous myself when I wrote my reply to your OP. I > refrained from mentioning it because it might have some unexpected side > effect we're not aware about. I know in at least some versions of IIS, the Anonymous SID is the one explicitly used for all not logged in www/ftp/etc clients connecting to IIS -- not sure if that would affect this discussion. -- Erik -- 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] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-24 22:36 ` Erik Soderquist @ 2016-06-24 23:03 ` Bill Zissimopoulos 2016-06-24 23:51 ` Bill Zissimopoulos 0 siblings, 1 reply; 23+ messages in thread From: Bill Zissimopoulos @ 2016-06-24 23:03 UTC (permalink / raw) To: cygwin On 6/24/16, 3:06 PM, "cygwin-owner@cygwin.com on behalf of Erik Soderquist" <cygwin-owner@cygwin.com on behalf of ErikSoderquist@gmail.com> wrote: >On Fri, Jun 24, 2016 at 5:59 PM, Corinna Vinschen wrote: >>> I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is >>>a >>> bad choice for some reason or other. >> >> I thought about Anonymous myself when I wrote my reply to your OP. I >> refrained from mentioning it because it might have some unexpected side >> effect we're not aware about. > >I know in at least some versions of IIS, the Anonymous SID is the one >explicitly used for all not logged in www/ftp/etc clients connecting >to IIS -- not sure if that would affect this discussion. It is my understanding that this is the intended use of the Anonymous SID. I have not thought enough to know whether it would fit properly in this use case. One caveat is that Cygwin already maps S-1-5-7 to uid 7. So does that mean that 7==nobody in Cygwin’s case? Bill ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-24 23:03 ` Bill Zissimopoulos @ 2016-06-24 23:51 ` Bill Zissimopoulos 2016-06-27 13:20 ` Corinna Vinschen 0 siblings, 1 reply; 23+ messages in thread From: Bill Zissimopoulos @ 2016-06-24 23:51 UTC (permalink / raw) To: cygwin On 6/24/16, 3:53 PM, "cygwin-owner@cygwin.com on behalf of Bill Zissimopoulos" <cygwin-owner@cygwin.com on behalf of billziss@navimatics.com> wrote: >One caveat is that Cygwin already maps S-1-5-7 to uid 7. So does that mean >that 7==nobody in Cygwin’s case? Here is output from Cygwin/SSHFS after mapping “nobody/nogroup” to S-1-5-7: << billziss@windows:~$ cd /cygdrive/y billziss@windows:/cygdrive/y$ ls -la total 8 drwxr-xr-x 1 billziss ANONYMOUS LOGON 0 Jun 23 23:57 . dr-xr-xr-x 1 billziss None 0 Jun 24 15:56 .. -rw-r--r-- 1 billziss ANONYMOUS LOGON 15 Jun 23 23:57 Foo.txt billziss@windows:/cygdrive/y$ cacls Foo.txt /S Y:\Foo.txt "D:P(A;;0x1f019f;;;S-1-5-21-383059176-2062642591-2866287538-1001)(A;;FR;;;A N)(A;;FR;;;WD)" billziss@windows:/cygdrive/y$ ls -lna total 8 drwxr-xr-x 1 197609 7 0 Jun 23 23:57 . dr-xr-xr-x 1 197609 197121 0 Jun 24 15:58 .. -rw-r--r-- 1 197609 7 15 Jun 23 23:57 Foo.txt billziss@windows:/cygdrive/y$ >> Opinions? Bill ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-24 23:51 ` Bill Zissimopoulos @ 2016-06-27 13:20 ` Corinna Vinschen 0 siblings, 0 replies; 23+ messages in thread From: Corinna Vinschen @ 2016-06-27 13:20 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1446 bytes --] On Jun 24 23:03, Bill Zissimopoulos wrote: > On 6/24/16, 3:53 PM, "cygwin-owner@cygwin.com on behalf of Bill > Zissimopoulos" <cygwin-owner@cygwin.com on behalf of > billziss@navimatics.com> wrote: > > > >One caveat is that Cygwin already maps S-1-5-7 to uid 7. So does that mean > >that 7==nobody in Cygwin’s case? > > Here is output from Cygwin/SSHFS after mapping “nobody/nogroup” to S-1-5-7: > << > billziss@windows:~$ cd /cygdrive/y > billziss@windows:/cygdrive/y$ ls -la > total 8 > drwxr-xr-x 1 billziss ANONYMOUS LOGON 0 Jun 23 23:57 . > dr-xr-xr-x 1 billziss None 0 Jun 24 15:56 .. > -rw-r--r-- 1 billziss ANONYMOUS LOGON 15 Jun 23 23:57 Foo.txt > billziss@windows:/cygdrive/y$ cacls Foo.txt /S > Y:\Foo.txt > "D:P(A;;0x1f019f;;;S-1-5-21-383059176-2062642591-2866287538-1001)(A;;FR;;;A > N)(A;;FR;;;WD)" > > billziss@windows:/cygdrive/y$ ls -lna > total 8 > drwxr-xr-x 1 197609 7 0 Jun 23 23:57 . > dr-xr-xr-x 1 197609 197121 0 Jun 24 15:58 .. > -rw-r--r-- 1 197609 7 15 Jun 23 23:57 Foo.txt > billziss@windows:/cygdrive/y$ > > >> > > > Opinions? Let's better not use anonymous. It could be a security risk. It might not do harm, but it also might give unwanted access rights in some scenarios. 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] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-24 22:31 ` Corinna Vinschen 2016-06-24 22:36 ` Erik Soderquist @ 2016-06-24 22:53 ` Bill Zissimopoulos 2016-06-25 17:10 ` Brian Inglis 2016-06-27 10:26 ` Bill Zissimopoulos 3 siblings, 0 replies; 23+ messages in thread From: Bill Zissimopoulos @ 2016-06-24 22:53 UTC (permalink / raw) To: cygwin On 6/24/16, 2:59 PM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf of corinna-cygwin@cygwin.com> wrote: >>>If you want some specific mapping we can arrange that, but it must not >> >be the NULL SID. If you know you're communicating with a Cygwin >>process, >> >what about using an arbitrary, unused SID like S-1-0-42? >> >> I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is a >> bad choice for some reason or other. > >I thought about Anonymous myself when I wrote my reply to your OP. I >refrained from mentioning it because it might have some unexpected side >effect we're not aware about. Let me try this with the Anonymous SID and see what happens. In the meantime I am going to ping some contacts from my MS days to see if there are indeed unintended consequences. >Keep in mind that Interix only supported standard POSIX permission bits. >Cygwin strives to support POSIX ACLs per POSIX 1003.1e draft 17. That's >a bit more extensive. Yes, that is beginning to dawn on me now that I have taken a better look at sec_acl.cc. Bill ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-24 22:31 ` Corinna Vinschen 2016-06-24 22:36 ` Erik Soderquist 2016-06-24 22:53 ` Bill Zissimopoulos @ 2016-06-25 17:10 ` Brian Inglis 2016-06-27 10:26 ` Bill Zissimopoulos 3 siblings, 0 replies; 23+ messages in thread From: Brian Inglis @ 2016-06-25 17:10 UTC (permalink / raw) To: cygwin > On Jun 24 21:37, Bill Zissimopoulos wrote: >> On 6/24/16, 12:51 PM, "Corinna Vinschen" <cygwin-owner <at> cygwin.com on >> behalf of corinna-cygwin <at> cygwin.com> wrote: >> I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is a >> bad choice for some reason or other. > I thought about Anonymous myself when I wrote my reply to your OP. I > refrained from mentioning it because it might have some unexpected side > effect we're not aware about. http://www.hsc.fr/ressources/articles/win_net_srv/null_sessions_intro.html indicates it is used for some MS RPC SMB named pipe services on IPC$ share such as lsarpc, samr, browser and for XP and backward compatibility. Document has embedded refs and biblio at end. -- 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] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-24 22:31 ` Corinna Vinschen ` (2 preceding siblings ...) 2016-06-25 17:10 ` Brian Inglis @ 2016-06-27 10:26 ` Bill Zissimopoulos 2016-06-27 10:29 ` Andrey Repin 3 siblings, 1 reply; 23+ messages in thread From: Bill Zissimopoulos @ 2016-06-27 10:26 UTC (permalink / raw) To: cygwin On 6/24/16, 2:59 PM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf of corinna-cygwin@cygwin.com> wrote: >>>If you want some specific mapping we can arrange that, but it must not >> >be the NULL SID. If you know you're communicating with a Cygwin >>process, >> >what about using an arbitrary, unused SID like S-1-0-42? >> >> I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is a >> bad choice for some reason or other. > >I thought about Anonymous myself when I wrote my reply to your OP. I >refrained from mentioning it because it might have some unexpected side >effect we're not aware about. I ended up implementing this a couple of days ago. I was just spending a lazy Sunday morning and then it hit me: this is an exceptionally bad idea. The problem is that Windows uses the Anonymous identity for accounts who have not logged in using a password (as per Erik Soderquist’s email regarding IIS behavior). Files in FUSE file systems that have a UID that cannot be mapped to a SID, will suddenly be owned by that Anonymous user! Obviously this is a huge security hole. I intend to fix this ASAP, but I am now back to where we started. The obvious SID to use is the NULL SID, but that is already used by Cygwin for other purposes. >> The main reason that I am weary of using an unused SID is that Microsoft >> may decide to assign some special powers to it in a future release (e.g. >> GodMode SID). But I agree that this is rather unlikely in the S-1-0-X >> namespace. > >I think it's very unlikely. We could chose any RID value we like and >the chance for collision is nil. When I created the new implementation >for POSIX ACLs, I toyed around with this already and used a special >Cygwin SID within the NULL SID AUTHORITY. I'm not entirely sure why I >changed this to the NULL SID deny ACE. I think I disliked the fact that >almost every Cygwin ACL would contain a mysterious "unknown SID". Ideally we should choose a SID that: (1) Is very unlikely to be used by Microsoft at any point in the future. (2) Cannot be associated to a user logon for any reason (see problem with Anonymous SID) above. (3) Maps to a reasonable UID in Cygwin. I propose the following SID/UID mapping: S-1-0-99 <=> UID 0xffffffff (32-bit -1) This is a SID in the S-1-0 (Null Authority) namespace (same one that contains the NULL SID), which is unlikely to be used by Microsoft. So it likely satisfies (1). For the same reason (that it is a new/unused SID in the S-1-0) namespace, I think it also satisfies (2). If we follow the rules from Cygwin’s "POSIX accounts, permission, and security” document [IDMAP], the SID S-1-0-99 maps to 0x10063. But we can make a special rule for this SID to map it to a different UID. Mapping it to -1 may be the easiest option, but perhaps we can also consider mapping it to 0xfffffffe (-2). Bill [IDMAP] https://cygwin.com/cygwin-ug-net/ntsec.html ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-27 10:26 ` Bill Zissimopoulos @ 2016-06-27 10:29 ` Andrey Repin 2016-06-27 12:06 ` Corinna Vinschen 0 siblings, 1 reply; 23+ messages in thread From: Andrey Repin @ 2016-06-27 10:29 UTC (permalink / raw) To: Bill Zissimopoulos, cygwin Greetings, Bill Zissimopoulos! >>> The main reason that I am weary of using an unused SID is that Microsoft >>> may decide to assign some special powers to it in a future release (e.g. >>> GodMode SID). But I agree that this is rather unlikely in the S-1-0-X >>> namespace. >> >>I think it's very unlikely. We could chose any RID value we like and >>the chance for collision is nil. When I created the new implementation >>for POSIX ACLs, I toyed around with this already and used a special >>Cygwin SID within the NULL SID AUTHORITY. I'm not entirely sure why I >>changed this to the NULL SID deny ACE. I think I disliked the fact that >>almost every Cygwin ACL would contain a mysterious "unknown SID". > Ideally we should choose a SID that: > (1) Is very unlikely to be used by Microsoft at any point in the future. > (2) Cannot be associated to a user logon for any reason (see problem with > Anonymous SID) above. > (3) Maps to a reasonable UID in Cygwin. > I propose the following SID/UID mapping: > S-1-0-99 <=> UID 0xffffffff (32-bit -1) Why not S-1-0-65535 ? It'll map to 0x1FFFF then without any special rules. > This is a SID in the S-1-0 (Null Authority) namespace (same one that > contains the NULL SID), which is unlikely to be used by Microsoft. So it > likely satisfies (1). > For the same reason (that it is a new/unused SID in the S-1-0) namespace, > I think it also satisfies (2). > If we follow the rules from Cygwin’s "POSIX accounts, permission, and > security” document [IDMAP], the SID S-1-0-99 maps to 0x10063. But we can > make a special rule for this SID to map it to a different UID. Mapping it > to -1 may be the easiest option, but perhaps we can also consider mapping > it to 0xfffffffe (-2). > Bill > [IDMAP] https://cygwin.com/cygwin-ug-net/ntsec.html -- With best regards, Andrey Repin Monday, June 27, 2016 12:08:13 Sorry for my terrible english... ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-27 10:29 ` Andrey Repin @ 2016-06-27 12:06 ` Corinna Vinschen 2016-06-27 20:31 ` Bill Zissimopoulos 0 siblings, 1 reply; 23+ messages in thread From: Corinna Vinschen @ 2016-06-27 12:06 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2760 bytes --] On Jun 27 12:23, Andrey Repin wrote: > Greetings, Bill Zissimopoulos! > > >>> The main reason that I am weary of using an unused SID is that Microsoft > >>> may decide to assign some special powers to it in a future release (e.g. > >>> GodMode SID). But I agree that this is rather unlikely in the S-1-0-X > >>> namespace. > >> > >>I think it's very unlikely. We could chose any RID value we like and > >>the chance for collision is nil. When I created the new implementation > >>for POSIX ACLs, I toyed around with this already and used a special > >>Cygwin SID within the NULL SID AUTHORITY. I'm not entirely sure why I > >>changed this to the NULL SID deny ACE. I think I disliked the fact that > >>almost every Cygwin ACL would contain a mysterious "unknown SID". > > > Ideally we should choose a SID that: > > > (1) Is very unlikely to be used by Microsoft at any point in the future. > > (2) Cannot be associated to a user logon for any reason (see problem with > > Anonymous SID) above. > > (3) Maps to a reasonable UID in Cygwin. > > > I propose the following SID/UID mapping: > > > S-1-0-99 <=> UID 0xffffffff (32-bit -1) > > Why not S-1-0-65535 ? It'll map to 0x1FFFF then without any special rules. The exact value of the RID isn't overly important. 99 is just as well as 65535. As for the mapping, it would always have to be special cased. The reason is that LookupAccountSid would balk at this SID so we have to add extra code to handle this SID anyway. > > This is a SID in the S-1-0 (Null Authority) namespace (same one that > > contains the NULL SID), which is unlikely to be used by Microsoft. So it > > likely satisfies (1). > > > For the same reason (that it is a new/unused SID in the S-1-0) namespace, > > I think it also satisfies (2). > > > If we follow the rules from Cygwin’s "POSIX accounts, permission, and > > security” document [IDMAP], the SID S-1-0-99 maps to 0x10063. But we can > > make a special rule for this SID to map it to a different UID. Mapping it > > to -1 may be the easiest option, but perhaps we can also consider mapping > > it to 0xfffffffe (-2). Why don't we just follow Fedora Linux here and use a mapping to either 99 (nobody) or 65534 (nfsnobody)? Both uid values are ununsed in the mapping and 65534 aka 0xfffe has the additional advantage that it's not mapped at all (all values between 0x1000 and 0xffff are invalid). Also, since 65534 is -2 in a 16 bit uid it seems like a natural choice to me. So, what about S-1-0-65534 <-> 65534, name of "{nfs}nobody"? 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] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-27 12:06 ` Corinna Vinschen @ 2016-06-27 20:31 ` Bill Zissimopoulos 2016-06-28 11:08 ` Corinna Vinschen 0 siblings, 1 reply; 23+ messages in thread From: Bill Zissimopoulos @ 2016-06-27 20:31 UTC (permalink / raw) To: cygwin >Why don't we just follow Fedora Linux here and use a mapping to either >99 (nobody) or 65534 (nfsnobody)? Both uid values are ununsed in the >mapping and 65534 aka 0xfffe has the additional advantage that it's not >mapped at all (all values between 0x1000 and 0xffff are invalid). > >Also, since 65534 is -2 in a 16 bit uid it seems like a natural choice >to me. > >So, what about S-1-0-65534 <-> 65534, name of "{nfs}nobody"? I am happy with the S-1-0-65534 *SID*, but I note that the 65534 *UID* is perhaps *not* a good choice. It is actually already mapped to S-1-5-15-4095, according to your own [IDMAP] document: S-1-5-X-RID <=> uid/gid: 0x1000 * X + RID With X=15 and RID=4095, we get uid==65534. Unfortunately S-1-5-15 is the SID for "This Organization” according to the “Well-known security identifiers in Windows operating systems” document [WKSID]. OTOH, because S-1-5-15 is a “leaf” SID and not a “namespace” it may be possible to assume that the S-1-5-15-4095 SID cannot appear (I am not sure about that). BTW, I have here a partitioning of the UID namespace that may help choose the right mapping: /* * UID namespace partitioning (from [IDMAP] rules): * * 0x000000 + RID S-1-5-RID,S-1-5-32-RID * 0x000ffe OtherSession * 0x000fff CurrentSession * 0x001000 * X + RID S-1-5-X-RID ([WKSID]: X=1-15,17-21,32,64,80,83) * 0x010000 + 0x100 * X + Y S-1-X-Y ([WKSID]: X=1,2,3,4,5,9,16) * 0x030000 + RID S-1-5-21-X-Y-Z-RID * 0x060000 + RID S-1-16-RID * 0x100000 + RID S-1-5-21-X-Y-Z-RID */ Clearly the namespace is very busy with multiple overlapping ranges. With all that and to help conclude this thread I gather here all the proposed mappings. Corinna, I will use the one which you prefer the most: S-1-0-65534 <-> 65534 S-1-0-65534 <-> -1==0xffffffff S-1-0-65534 <-> -2==0xfffffffe S-1-0-99 <-> -1==0xffffffff S-1-0-99 <-> -2==0xfffffffe Bill [IDMAP] https://cygwin.com/cygwin-ug-net/ntsec.html [WKSID] https://support.microsoft.com/en-us/kb/243330 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-27 20:31 ` Bill Zissimopoulos @ 2016-06-28 11:08 ` Corinna Vinschen 2016-06-28 19:17 ` Bill Zissimopoulos 0 siblings, 1 reply; 23+ messages in thread From: Corinna Vinschen @ 2016-06-28 11:08 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 3301 bytes --] On Jun 27 19:01, Bill Zissimopoulos wrote: > > >Why don't we just follow Fedora Linux here and use a mapping to either > >99 (nobody) or 65534 (nfsnobody)? Both uid values are ununsed in the > >mapping and 65534 aka 0xfffe has the additional advantage that it's not > >mapped at all (all values between 0x1000 and 0xffff are invalid). > > > >Also, since 65534 is -2 in a 16 bit uid it seems like a natural choice > >to me. > > > >So, what about S-1-0-65534 <-> 65534, name of "{nfs}nobody"? > > I am happy with the S-1-0-65534 *SID*, but I note that the 65534 *UID* is > perhaps *not* a good choice. It is actually already mapped to > S-1-5-15-4095, according to your own [IDMAP] document: > > S-1-5-X-RID <=> uid/gid: 0x1000 * X + RID > > With X=15 and RID=4095, we get uid==65534. This doesn't make any sense. This is an entirely artificial example of how one can construct arbitrary SIDs. > Unfortunately S-1-5-15 is the > SID for "This Organization” according to the “Well-known security > identifiers in Windows operating systems” document [WKSID]. OTOH, because > S-1-5-15 is a “leaf” SID and not a “namespace” it may be possible to > assume that the S-1-5-15-4095 SID cannot appear (I am not sure about that). There is no such SID and there never will be. Ok. Please keep in mind that a) there can't be a bijective mapping between arbitrary length SIDs and a 32 bit uid/gid. b) The mapping used in Cygwin is not self-created but (mostly, except for a single deviation) identical to the Interix mapping. The code basically follows how this mapping has been defined by Microsoft. > BTW, I have here a partitioning of the UID namespace that may help choose > the right mapping: > > /* > * UID namespace partitioning (from [IDMAP] rules): > * > * 0x000000 + RID S-1-5-RID,S-1-5-32-RID > * 0x000ffe OtherSession > * 0x000fff CurrentSession > * 0x001000 * X + RID S-1-5-X-RID ([WKSID]: > X=1-15,17-21,32,64,80,83) > * 0x010000 + 0x100 * X + Y S-1-X-Y ([WKSID]: X=1,2,3,4,5,9,16) > * 0x030000 + RID S-1-5-21-X-Y-Z-RID > * 0x060000 + RID S-1-16-RID > * 0x100000 + RID S-1-5-21-X-Y-Z-RID > */ You're aware that I wrote the code for this mapping as well as its documentation? :) > Clearly the namespace is very busy with multiple overlapping ranges. The overlapping is much alleviated by the fact that only certain SIDs can exist, plus the fact that AD admins can choose an offset value for AD accounts of various domains. Search for "trustPosixOffset" in https://cygwin.com/cygwin-ug-net/ntsec.html. > With all that and to help conclude this thread I gather here all the > proposed mappings. Corinna, I will use the one which you prefer the most: > > S-1-0-65534 <-> 65534 This one is still my favorite. Again, the range from 0x1000 up to 0xffff is unused. Right now any incoming uid/gid value in this range for a reverse SID lookup is treated as invalid SID. 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] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-28 11:08 ` Corinna Vinschen @ 2016-06-28 19:17 ` Bill Zissimopoulos 2016-06-28 19:17 ` John Ruckstuhl 2016-06-29 8:43 ` Corinna Vinschen 0 siblings, 2 replies; 23+ messages in thread From: Bill Zissimopoulos @ 2016-06-28 19:17 UTC (permalink / raw) To: cygwin On 6/28/16, 3:27 AM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf of corinna-cygwin@cygwin.com> wrote: >>Ok. Please keep in mind that > >a) there can't be a bijective mapping between arbitrary length SIDs > and a 32 bit uid/gid. > >b) The mapping used in Cygwin is not self-created but (mostly, except > for a single deviation) identical to the Interix mapping. The code > basically follows how this mapping has been defined by Microsoft. Corinna, please stop explaining things to me that I already know. >> BTW, I have here a partitioning of the UID namespace that may help >>choose >> the right mapping: >> >> /* >> * UID namespace partitioning (from [IDMAP] rules): >> * >> * 0x000000 + RID S-1-5-RID,S-1-5-32-RID >> * 0x000ffe OtherSession >> * 0x000fff CurrentSession >> * 0x001000 * X + RID S-1-5-X-RID ([WKSID]: >> X=1-15,17-21,32,64,80,83) >> * 0x010000 + 0x100 * X + Y S-1-X-Y ([WKSID]: X=1,2,3,4,5,9,16) >> * 0x030000 + RID S-1-5-21-X-Y-Z-RID >> * 0x060000 + RID S-1-16-RID >> * 0x100000 + RID S-1-5-21-X-Y-Z-RID >> */ > >You're aware that I wrote the code for this mapping as well as its >documentation? :) Corinna, of course I am aware of that. I have found your original post to this list about it. Why would you think otherwise? And why would it change anything? >>With all that and to help conclude this thread I gather here all the >> proposed mappings. Corinna, I will use the one which you prefer the >>most: >> >> S-1-0-65534 <-> 65534 > >This one is still my favorite. Again, the range from 0x1000 up to >0xffff is unused. Right now any incoming uid/gid value in this range >for a reverse SID lookup is treated as invalid SID. I disagree. You are saying that it is unused, but a (perhaps erroneous) SID would map into that space. In any case I will use your mapping of S-1-0-65534 <-> 65534. Bill ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-28 19:17 ` Bill Zissimopoulos @ 2016-06-28 19:17 ` John Ruckstuhl 2016-06-29 8:43 ` Corinna Vinschen 1 sibling, 0 replies; 23+ messages in thread From: John Ruckstuhl @ 2016-06-28 19:17 UTC (permalink / raw) To: cygwin Since these emails go to a list, not just Bill, and are archived, the extra detail is added value and appreciated by other people now & in future. On Tue, Jun 28, 2016 at 11:06 AM, Bill Zissimopoulos <billziss@navimatics.com> wrote: > On 6/28/16, 3:27 AM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf > of corinna-cygwin@cygwin.com> wrote: > > >>>Ok. Please keep in mind that >> >>a) there can't be a bijective mapping between arbitrary length SIDs >> and a 32 bit uid/gid. >> >>b) The mapping used in Cygwin is not self-created but (mostly, except >> for a single deviation) identical to the Interix mapping. The code >> basically follows how this mapping has been defined by Microsoft. > > Corinna, please stop explaining things to me that I already know. > >>> BTW, I have here a partitioning of the UID namespace that may help >>>choose >>> the right mapping: >>> >>> /* >>> * UID namespace partitioning (from [IDMAP] rules): >>> * >>> * 0x000000 + RID S-1-5-RID,S-1-5-32-RID >>> * 0x000ffe OtherSession >>> * 0x000fff CurrentSession >>> * 0x001000 * X + RID S-1-5-X-RID ([WKSID]: >>> X=1-15,17-21,32,64,80,83) >>> * 0x010000 + 0x100 * X + Y S-1-X-Y ([WKSID]: X=1,2,3,4,5,9,16) >>> * 0x030000 + RID S-1-5-21-X-Y-Z-RID >>> * 0x060000 + RID S-1-16-RID >>> * 0x100000 + RID S-1-5-21-X-Y-Z-RID >>> */ >> >>You're aware that I wrote the code for this mapping as well as its >>documentation? :) > > Corinna, of course I am aware of that. I have found your original post to > this list about it. Why would you think otherwise? And why would it change > anything? > >>>With all that and to help conclude this thread I gather here all the >>> proposed mappings. Corinna, I will use the one which you prefer the >>>most: >>> >>> S-1-0-65534 <-> 65534 >> >>This one is still my favorite. Again, the range from 0x1000 up to >>0xffff is unused. Right now any incoming uid/gid value in this range >>for a reverse SID lookup is treated as invalid SID. > > I disagree. You are saying that it is unused, but a (perhaps erroneous) > SID would map into that space. > > In any case I will use your mapping of S-1-0-65534 <-> 65534. > > Bill > -- 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] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-28 19:17 ` Bill Zissimopoulos 2016-06-28 19:17 ` John Ruckstuhl @ 2016-06-29 8:43 ` Corinna Vinschen 2016-06-29 15:14 ` Corinna Vinschen 2016-06-30 9:26 ` Bill Zissimopoulos 1 sibling, 2 replies; 23+ messages in thread From: Corinna Vinschen @ 2016-06-29 8:43 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 3553 bytes --] On Jun 28 18:06, Bill Zissimopoulos wrote: > On 6/28/16, 3:27 AM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf > of corinna-cygwin@cygwin.com> wrote: > > > >>Ok. Please keep in mind that > > > >a) there can't be a bijective mapping between arbitrary length SIDs > > and a 32 bit uid/gid. > > > >b) The mapping used in Cygwin is not self-created but (mostly, except > > for a single deviation) identical to the Interix mapping. The code > > basically follows how this mapping has been defined by Microsoft. > > Corinna, please stop explaining things to me that I already know. Sorry but I don't grok this. During this discussion you were explaining things to me which I obviously had to know. If I'm explainig things to you you already know, well, sorry about that. Your attempt at creating an artificial SID just to prove that a collision could be constructed looked like you didn't understand how well-known Windows SIDs work and are constructed, and that there's no way for a collision from a valid Windows SID here. > >> BTW, I have here a partitioning of the UID namespace that may help > >>choose > >> the right mapping: > >> > >> /* > >> * UID namespace partitioning (from [IDMAP] rules): > >> * > >> * 0x000000 + RID S-1-5-RID,S-1-5-32-RID > >> * 0x000ffe OtherSession > >> * 0x000fff CurrentSession > >> * 0x001000 * X + RID S-1-5-X-RID ([WKSID]: > >> X=1-15,17-21,32,64,80,83) > >> * 0x010000 + 0x100 * X + Y S-1-X-Y ([WKSID]: X=1,2,3,4,5,9,16) > >> * 0x030000 + RID S-1-5-21-X-Y-Z-RID > >> * 0x060000 + RID S-1-16-RID > >> * 0x100000 + RID S-1-5-21-X-Y-Z-RID > >> */ > > > >You're aware that I wrote the code for this mapping as well as its > >documentation? :) > > Corinna, of course I am aware of that. I have found your original post to > this list about it. Why would you think otherwise? And why would it change > anything? If that's the case, then why do you explain all these things to me? I'm a bit at a loss to see the difference between me explaining things to you you already know vs. you explaing things to me I already know. Aren't we kind of on par here? But, never mind. > >>With all that and to help conclude this thread I gather here all the > >> proposed mappings. Corinna, I will use the one which you prefer the > >>most: > >> > >> S-1-0-65534 <-> 65534 > > > >This one is still my favorite. Again, the range from 0x1000 up to > >0xffff is unused. Right now any incoming uid/gid value in this range > >for a reverse SID lookup is treated as invalid SID. > > I disagree. You are saying that it is unused, but a (perhaps erroneous) > SID would map into that space. Yes that's possible. However, where would this erroneous SID come from? The chances that a SID comes in which gets converted to uid/gid 0xfffffffe is actually higher. See UNIX_POSIX_OFFSET. > In any case I will use your mapping of S-1-0-65534 <-> 65534. Thanks. Do you want to add handling for this mapping to pwdgrp::fetch_account_from_windows yourself or shall I do it? I could come up with a patch in the next couple of days. I will prepare a developer's snapshot then, so you can immediately test if it works as desired. Thanks again, 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] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-29 8:43 ` Corinna Vinschen @ 2016-06-29 15:14 ` Corinna Vinschen 2016-06-29 16:06 ` Corinna Vinschen 2016-06-30 9:26 ` Bill Zissimopoulos 1 sibling, 1 reply; 23+ messages in thread From: Corinna Vinschen @ 2016-06-29 15:14 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 808 bytes --] Hi Bill, On Jun 29 10:21, Corinna Vinschen wrote: > On Jun 28 18:06, Bill Zissimopoulos wrote: > > In any case I will use your mapping of S-1-0-65534 <-> 65534. > > Thanks. Do you want to add handling for this mapping to > pwdgrp::fetch_account_from_windows yourself or shall I do it? I could > come up with a patch in the next couple of days. I will prepare a > developer's snapshot then, so you can immediately test if it works as > desired. How do we avoid name collisions? I can easily see admins creating an AD account called "nobody". Shall we fake a "WinFSP" domain such that the name is "WinFSP+nobody"? 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] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-29 15:14 ` Corinna Vinschen @ 2016-06-29 16:06 ` Corinna Vinschen 0 siblings, 0 replies; 23+ messages in thread From: Corinna Vinschen @ 2016-06-29 16:06 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 904 bytes --] On Jun 29 15:45, Corinna Vinschen wrote: > Hi Bill, > > On Jun 29 10:21, Corinna Vinschen wrote: > > On Jun 28 18:06, Bill Zissimopoulos wrote: > > > In any case I will use your mapping of S-1-0-65534 <-> 65534. > > > > Thanks. Do you want to add handling for this mapping to > > pwdgrp::fetch_account_from_windows yourself or shall I do it? I could > > come up with a patch in the next couple of days. I will prepare a > > developer's snapshot then, so you can immediately test if it works as > > desired. > > How do we avoid name collisions? I can easily see admins creating an > AD account called "nobody". > > Shall we fake a "WinFSP" domain such that the name is "WinFSP+nobody"? Preliminary patch attached. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #1.2: 0001-Handle-WinFSP-nobody-account.patch --] [-- Type: text/plain, Size: 2102 bytes --] From a0bdba1cc4b8515e933e1c1caf59fcc310c48613 Mon Sep 17 00:00:00 2001 From: Corinna Vinschen <corinna@vinschen.de> Date: Wed, 29 Jun 2016 17:12:38 +0200 Subject: [PATCH] Handle WinFSP nobody account Per discussion started at https://cygwin.com/ml/cygwin/2016-06/msg00347.html S-1-0-65534 == WinFSP\nobody == WinFSP+nobody == uid/gid 65534 --- winsup/cygwin/uinfo.cc | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc index 247131d..af1a4e5 100644 --- a/winsup/cygwin/uinfo.cc +++ b/winsup/cygwin/uinfo.cc @@ -1894,6 +1894,14 @@ pwdgrp::fetch_account_from_windows (fetch_user_arg_t &arg, cyg_ldap *pldap) } if (!ret) { + if (!strcmp (arg.name, "WinFSP+nobody")) + { + /* Special case "nobody" for reproducible construction of a + nobody SID for WinFSP. We use the value 65534 which is + -2 with 16 bit uid/gids. */ + csid.create (0, 1, 0xfffe); + break; + } debug_printf ("LookupAccountNameW (%W), %E", name); return NULL; } @@ -2004,6 +2012,15 @@ pwdgrp::fetch_account_from_windows (fetch_user_arg_t &arg, cyg_ldap *pldap) sid = logon_sid; break; } + else if (arg.id == 0xfffe) + { + /* Special case "nobody" for reproducible construction of a + nobody SID for WinFSP. We use the value 65534 which is + -2 with 16 bit uid/gids. */ + csid.create (0, 1, 0xfffe); + sid = csid; + break; + } else if (arg.id < 0x10000) { /* Nothing. */ @@ -2428,6 +2445,14 @@ pwdgrp::fetch_account_from_windows (fetch_user_arg_t &arg, cyg_ldap *pldap) return NULL; } } + else if (sid_id_auth (sid) == 0 && sid_sub_auth (sid, 0) == 0xfffe) + { + uid = gid = 0xfffe; + wcpcpy (dom, L"WinFSP"); + wcpcpy (name = namebuf, L"nobody"); + fully_qualified_name = true; + acc_type = SidTypeUnknown; + } else if (sid_id_auth (sid) == 5 /* SECURITY_NT_AUTHORITY */ && sid_sub_auth (sid, 0) == SECURITY_LOGON_IDS_RID) { -- 2.5.5 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-29 8:43 ` Corinna Vinschen 2016-06-29 15:14 ` Corinna Vinschen @ 2016-06-30 9:26 ` Bill Zissimopoulos 2016-06-30 14:15 ` Corinna Vinschen 1 sibling, 1 reply; 23+ messages in thread From: Bill Zissimopoulos @ 2016-06-30 9:26 UTC (permalink / raw) To: cygwin On 6/29/16, 1:21 AM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf of corinna-cygwin@cygwin.com> wrote: >If that's the case, then why do you explain all these things to me? I'm >a bit at a loss to see the difference between me explaining things to >you you already know vs. you explaing things to me I already know. >Aren't we kind of on par here? Yes, we are. Perhaps I spoke “out of turn” as the Americans say. I am sorry if it also felt like I was explaining things that you know. >>In any case I will use your mapping of S-1-0-65534 <-> 65534. > >Thanks. Do you want to add handling for this mapping to >pwdgrp::fetch_account_from_windows yourself or shall I do it? I could >come up with a patch in the next couple of days. I will prepare a >developer's snapshot then, so you can immediately test if it works as >desired. I have already added the mapping to WinFsp-FUSE. I can look into what is required to patch Cygwin. >>How do we avoid name collisions? I can easily see admins creating an >>AD account called "nobody". >>Shall we fake a "WinFSP" domain such that the name is "WinFSP+nobody"? > >Preliminary patch attached. Ok, looks like you have patched it already. Thanks for this. BTW, if the name is case-sensitive (strcmp) I usually use the “WinFsp” capitalization, if it makes a difference. Also do you foresee any situation where the “nobody” mapping might be useful outside of WinFsp? Perhaps it would make more sense to name it “nodomain+nobody”? Just a suggestion. Many thanks. Bill ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: POSIX permission mapping and NULL SIDs 2016-06-30 9:26 ` Bill Zissimopoulos @ 2016-06-30 14:15 ` Corinna Vinschen 0 siblings, 0 replies; 23+ messages in thread From: Corinna Vinschen @ 2016-06-30 14:15 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1089 bytes --] On Jun 30 00:03, Bill Zissimopoulos wrote: > On 6/29/16, 1:21 AM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf > of corinna-cygwin@cygwin.com> wrote: > >>How do we avoid name collisions? I can easily see admins creating an > >>AD account called "nobody". > >>Shall we fake a "WinFSP" domain such that the name is "WinFSP+nobody"? > > > >Preliminary patch attached. > > Ok, looks like you have patched it already. Thanks for this. > > BTW, if the name is case-sensitive (strcmp) I usually use the “WinFsp” > capitalization, if it makes a difference. It shouldn't, but of course I'd fix that to use your capitalization. After all it's your project :) > Also do you foresee any situation where the “nobody” mapping might be > useful outside of WinFsp? Perhaps it would make more sense to name it > “nodomain+nobody”? Just a suggestion. Hmm, yes, maybe. Funny idea: "no+body" :) 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] 23+ messages in thread
end of thread, other threads:[~2016-06-30 13:48 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-24 19:02 POSIX permission mapping and NULL SIDs Bill Zissimopoulos 2016-06-24 21:37 ` Corinna Vinschen 2016-06-24 22:00 ` Corinna Vinschen 2016-06-24 22:06 ` Bill Zissimopoulos 2016-06-24 22:31 ` Corinna Vinschen 2016-06-24 22:36 ` Erik Soderquist 2016-06-24 23:03 ` Bill Zissimopoulos 2016-06-24 23:51 ` Bill Zissimopoulos 2016-06-27 13:20 ` Corinna Vinschen 2016-06-24 22:53 ` Bill Zissimopoulos 2016-06-25 17:10 ` Brian Inglis 2016-06-27 10:26 ` Bill Zissimopoulos 2016-06-27 10:29 ` Andrey Repin 2016-06-27 12:06 ` Corinna Vinschen 2016-06-27 20:31 ` Bill Zissimopoulos 2016-06-28 11:08 ` Corinna Vinschen 2016-06-28 19:17 ` Bill Zissimopoulos 2016-06-28 19:17 ` John Ruckstuhl 2016-06-29 8:43 ` Corinna Vinschen 2016-06-29 15:14 ` Corinna Vinschen 2016-06-29 16:06 ` Corinna Vinschen 2016-06-30 9:26 ` Bill Zissimopoulos 2016-06-30 14:15 ` 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).