* Problem with "None" Group on Non-Domain Members @ 2014-05-05 13:49 Chris J. Breisch 2014-05-05 13:59 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Chris J. Breisch @ 2014-05-05 13:49 UTC (permalink / raw) To: cygwin Hi, I noticed this over the weekend. It's probably working as designed, however. And may have even been noticed by others before. As has been noted in the past, if your machine is not a Domain member, your account gets assigned to the "None" group. And it's your default group as well. The problem is that the "None" group isn't very well behaved when it comes to permissions. Example below. $ mkdir none-group-test $ cd none-group-test/ $ touch foo $ ls -l foo -rw-rw-r-- 1 Chris None 0 May 5 09:35 foo $ chmod 600 foo $ ls -l foo -rw-rw---- 1 Chris None 0 May 5 09:35 foo $ chgrp Users foo $ chmod 600 foo $ ls -l foo -rw------- 1 Chris Users 0 May 5 09:35 foo When the group for a file or directory is set to "None", the group permissions always mimic the owner permissions. I assume this is nothing Cygwin has control over. But, this causes problems for programs like SSH which expect some of its files to be locked down and only owner accessible. Since "None" is the default group, this can be rather irksome. As a workaround, I changed my default group in /etc/passwd from "None" (513) to "Users" (545). That worked fine. However, I wonder two things: 1) Do we have to make "None" be the default group in a non-Domain environment? Is this something that could be set by mkpasswd? I realize this is a Windows Group and Cygwin is just doing what Windows tells it to do, but maybe that's not the best idea in this case. 2) How is this all going to work with Corinna's new stuff? Will I even be able to change my default group with it? Just to be clear, this is only a problem on non-Domain accounts. For a Domain account the default group is "Domain Users" (513) rather than "None" (513), and "Domain Users" is well-behaved. -- Chris J. Breisch -- 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] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 13:49 Problem with "None" Group on Non-Domain Members Chris J. Breisch @ 2014-05-05 13:59 ` Corinna Vinschen 2014-05-05 14:17 ` Chris J. Breisch 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2014-05-05 13:59 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1451 bytes --] On May 5 09:49, Chris J. Breisch wrote: > Hi, > > I noticed this over the weekend. It's probably working as designed, > however. And may have even been noticed by others before. > > As has been noted in the past, if your machine is not a Domain > member, your account gets assigned to the "None" group. And it's > your default group as well. The problem is that the "None" group > isn't very well behaved when it comes to permissions. > > Example below. > > $ mkdir none-group-test > $ cd none-group-test/ > $ touch foo > $ ls -l foo > -rw-rw-r-- 1 Chris None 0 May 5 09:35 foo > $ chmod 600 foo > $ ls -l foo > -rw-rw---- 1 Chris None 0 May 5 09:35 foo > $ chgrp Users foo > $ chmod 600 foo > $ ls -l foo > -rw------- 1 Chris Users 0 May 5 09:35 foo As far as Cygwin tools are concerned, the None group is just a normal group like any other group. The behaviour you're observing looks a bit like either your group file is not ok, or you're testing this with the noacl mount option. Or, probably more likely, you're suffereing from the default ACL settings propagated from the parent directory. When Cygwin sets the POSIX permissions, it does exactly the same thing for the primary group in your token, whether it's None or any other group. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 13:59 ` Corinna Vinschen @ 2014-05-05 14:17 ` Chris J. Breisch 2014-05-05 14:47 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Chris J. Breisch @ 2014-05-05 14:17 UTC (permalink / raw) To: cygwin Corinna Vinschen wrote: > On May 5 09:49, Chris J. Breisch wrote: > As far as Cygwin tools are concerned, the None group is just a normal > group like any other group. The behaviour you're observing looks a bit > like either your group file is not ok, or you're testing this with the > noacl mount option. Or, probably more likely, you're suffereing from > the default ACL settings propagated from the parent directory. > > When Cygwin sets the POSIX permissions, it does exactly the same thing > for the primary group in your token, whether it's None or any other > group. > > I understand what you're saying, but I don't think the behavior agrees with your statements. I've tried this on a couple different machines, and the behavior is identical. No matter what I do, if a file is created with the "None" group, the group file permissions are always identical to the owner file permissions. I've tried playing with my umask and with directory sticky bits. It doesn't matter. In the example above, my parent directory is rather oddly, Chris.Users 000. The current directory is Chris.None 775. $ ls -ld . .. drwxrwxr-x+ 1 Chris None 0 May 5 10:05 ./ d---------+ 1 Chris Users 0 May 5 09:35 ../ And again, changing the permissions of the directory doesn't accomplish anything: $ chmod 755 . $ ls -ld . .. drwxrwxr-x+ 1 Chris None 0 May 5 10:08 ./ d---------+ 1 Chris Users 0 May 5 10:08 ../ Changing the group for the directory doesn't help either: $ chgrp Users . $ touch bar $ ls -l bar -rw-rw-r-- 1 Chris None 0 May 5 10:10 bar $ chmod 600 bar $ ls -l bar -rw-rw---- 1 Chris None 0 May 5 10:10 bar $ ls -ld . .. drwxrwxr-x+ 1 Chris Users 0 May 5 10:10 ./ d---------+ 1 Chris Users 0 May 5 10:08 ../ Taking the example one step farther: $ chmod 600 bar $ ls -l bar -rw-rw---- 1 Chris None 0 May 5 10:10 bar $ chmod 400 bar $ ls -l bar -r--r----- 1 Chris None 0 May 5 10:10 bar And changing the group from "None" to anything else always fixes the permission issues. chmod and umask suddenly start working as expected. -- Chris J. Breisch -- 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] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 14:17 ` Chris J. Breisch @ 2014-05-05 14:47 ` Corinna Vinschen 2014-05-05 15:23 ` Chris J. Breisch 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2014-05-05 14:47 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2486 bytes --] On May 5 10:17, Chris J. Breisch wrote: > Corinna Vinschen wrote: > >On May 5 09:49, Chris J. Breisch wrote: > >As far as Cygwin tools are concerned, the None group is just a normal > >group like any other group. The behaviour you're observing looks a bit > >like either your group file is not ok, or you're testing this with the > >noacl mount option. Or, probably more likely, you're suffereing from > >the default ACL settings propagated from the parent directory. > > > >When Cygwin sets the POSIX permissions, it does exactly the same thing > >for the primary group in your token, whether it's None or any other > >group. > > > > > I understand what you're saying, but I don't think the behavior > agrees with your statements. I've tried this on a couple different > machines, and the behavior is identical. No matter what I do, if a > file is created with the "None" group, the group file permissions > are always identical to the owner file permissions. I've tried > playing with my umask and with directory sticky bits. It doesn't > matter. I wasn't talking about the POSIX permissions, but about the Windows ACL. In your current dir, what does `icacls .' print? Maybe that gives a clue. > In the example above, my parent directory is rather oddly, > Chris.Users 000. The current directory is Chris.None 775. I just tried it myself with a local machine account and I can't reproduce this. My pgid is "None" and the umask of 0022 leads to the expected POSIX permissions: vmbert8164+lcorinna@vmbert8164 ~ $ umask 0022 vmbert8164+lcorinna@vmbert8164 ~ $ touch bar vmbert8164+lcorinna@vmbert8164 ~ $ ls -l total 0 -rw-r--r-- 1 vmbert8164+lcorinna vmbert8164+None 0 May 5 16:41 bar > [...] > Taking the example one step farther: > > $ chmod 600 bar > $ ls -l bar > -rw-rw---- 1 Chris None 0 May 5 10:10 bar > $ chmod 400 bar > $ ls -l bar > -r--r----- 1 Chris None 0 May 5 10:10 bar vmbert8164+lcorinna@vmbert8164 ~ $ chmod 400 bar vmbert8164+lcorinna@vmbert8164 ~ $ ls -l bar -r-------- 1 vmbert8164+lcorinna vmbert8164+None 0 May 5 16:41 bar So I'd say it's not a generic issue but something in your environment. It would be nice to know what that is, of course. Maybe there's some security setting?!? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 14:47 ` Corinna Vinschen @ 2014-05-05 15:23 ` Chris J. Breisch 2014-05-05 15:42 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Chris J. Breisch @ 2014-05-05 15:23 UTC (permalink / raw) To: cygwin Corinna Vinschen wrote: > > I wasn't talking about the POSIX permissions, but about the Windows > ACL. In your current dir, what does `icacls .' print? Maybe that > gives a clue. Mea culpa. I should read better. I could have included that the last time. $ icacls . . WIN8-VM\Chris:(F) BUILTIN\Users:(RX) Everyone:(RX) NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files That doesn't seem too terribly strange to me. > >> [...] >> Taking the example one step farther: >> >> $ chmod 600 bar >> $ ls -l bar >> -rw-rw---- 1 Chris None 0 May 5 10:10 bar >> $ chmod 400 bar >> $ ls -l bar >> -r--r----- 1 Chris None 0 May 5 10:10 bar > > vmbert8164+lcorinna@vmbert8164 ~ > $ chmod 400 bar > > vmbert8164+lcorinna@vmbert8164 ~ > $ ls -l bar > -r-------- 1 vmbert8164+lcorinna vmbert8164+None 0 May 5 16:41 bar > > So I'd say it's not a generic issue but something in your environment. > It would be nice to know what that is, of course. Maybe there's some > security setting?!? > Thanks for looking into this, Corinna. Apparently this is my problem, and not a Cygwin/Windows issue. That's rather odd, because the two machines I have tested this on are nothing alike, other than both being Windows 8.1 machines. They weren't even set up by the same people, or following the same (or any) script. In both cases, I am logging on to the machine with a "Microsoft Account": http://www.microsoft.com/en-us/account/default.aspx I can attach a cygcheck if you think there's any value in it. Doesn't seem likely, though. I'm looking at what's installed on the machine. More than I thought, but there doesn't appear to be any BLODA. I may try to create a new VM with nothing on it but Cygwin and see what happens. I don't have access to the second machine right now, but I'll dig later. I'll dig a little more on my own. I don't want to waste bandwidth on the Cygwin list for what appears to be a Stupid User Error. Thanks again. -- Chris J. Breisch -- 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] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 15:23 ` Chris J. Breisch @ 2014-05-05 15:42 ` Corinna Vinschen 2014-05-05 16:17 ` Chris J. Breisch 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2014-05-05 15:42 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2851 bytes --] On May 5 11:23, Chris J. Breisch wrote: > Corinna Vinschen wrote: > > > >I wasn't talking about the POSIX permissions, but about the Windows > >ACL. In your current dir, what does `icacls .' print? Maybe that > >gives a clue. > > Mea culpa. I should read better. I could have included that the last time. > > $ icacls . > . WIN8-VM\Chris:(F) > BUILTIN\Users:(RX) > Everyone:(RX) > NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M) > CREATOR OWNER:(OI)(CI)(IO)(F) > CREATOR GROUP:(OI)(CI)(IO)(RX) > Everyone:(OI)(CI)(IO)(RX) > > Successfully processed 1 files; Failed processing 0 files > > That doesn't seem too terribly strange to me. > > > > >>[...] > >>Taking the example one step farther: > >> > >>$ chmod 600 bar > >>$ ls -l bar > >>-rw-rw---- 1 Chris None 0 May 5 10:10 bar > >>$ chmod 400 bar > >>$ ls -l bar > >>-r--r----- 1 Chris None 0 May 5 10:10 bar > > > > vmbert8164+lcorinna@vmbert8164 ~ > > $ chmod 400 bar > > > > vmbert8164+lcorinna@vmbert8164 ~ > > $ ls -l bar > > -r-------- 1 vmbert8164+lcorinna vmbert8164+None 0 May 5 16:41 bar > > > >So I'd say it's not a generic issue but something in your environment. > >It would be nice to know what that is, of course. Maybe there's some > >security setting?!? > > > > Thanks for looking into this, Corinna. Apparently this is my > problem, and not a Cygwin/Windows issue. That's rather odd, because > the two machines I have tested this on are nothing alike, other than > both being Windows 8.1 machines. They weren't even set up by the > same people, or following the same (or any) script. > > In both cases, I am logging on to the machine with a "Microsoft > Account": http://www.microsoft.com/en-us/account/default.aspx Hmm, maybe that's the problem. This "Microsoft Account" stuff might influence how the underlying OS handles permissions. I would never touch this stuff ;) For testing you could try to create a normal local account, add it to /etc/passwd and run the above under this account. If it behaves differently (correct, that is), it's a something weird with these MS accounts. But then again, I wouldn't know how to "fix" this, other than to suggest to use a normal account instead. > I'll dig a little more on my own. I don't want to waste bandwidth on > the Cygwin list for what appears to be a Stupid User Error. Nah, at this point we really don't know why this happens on your machine and it could easily be somebody elses fault. An strace of `chmod 400 bar' might sched some light on this issue, but I have a gut feeling the underlying WIndows call will not even return an error code... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 15:42 ` Corinna Vinschen @ 2014-05-05 16:17 ` Chris J. Breisch 2014-05-05 16:57 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Chris J. Breisch @ 2014-05-05 16:17 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1870 bytes --] Corinna Vinschen wrote: > On May 5 11:23, Chris J. Breisch wrote: >> In both cases, I am logging on to the machine with a "Microsoft >> Account": http://www.microsoft.com/en-us/account/default.aspx > > Hmm, maybe that's the problem. This "Microsoft Account" stuff might > influence how the underlying OS handles permissions. I would never > touch this stuff ;) I don't blame you. And I don't think you can use them on a machine that's a member of a domain, but I could be mistaken there. They're local accounts, but definitely with a twist. I was pleasantly surprised that ssh didn't choke on them, but I didn't really suspect it as a root cause for file permission issues, or I would have mentioned that in my very first message. > > For testing you could try to create a normal local account, add it to > /etc/passwd and run the above under this account. If it behaves > differently (correct, that is), it's a something weird with these MS > accounts. But then again, I wouldn't know how to "fix" this, other > than to suggest to use a normal account instead. Bingo. I had just such an account already. It works as expected, i.e. correctly. Could we "fix" it by allowing the user to set their default group? As I said in my original message, changing the group from None to Users in /etc/passwd solved my problems. Of course, if we don't really understand these accounts, then we don't know why that solved my problem, or if the same thing would work for someone else. Hmmm. Never mind. > Nah, at this point we really don't know why this happens on your machine > and it could easily be somebody elses fault. > > An strace of `chmod 400 bar' might sched some light on this issue, but I > have a gut feeling the underlying WIndows call will not even return an > error code... Attached. Your gut seems to be working today... -- Chris J. Breisch [-- Attachment #2: strace.out --] [-- Type: text/plain, Size: 31262 bytes --] 13 13 [main] chmod (5536) ********************************************** 24 37 [main] chmod (5536) Program name: C:\cygwin\AMD64\bin\chmod.exe (windows pid 5536) 2 39 [main] chmod (5536) OS version: Windows NT-6.3 1 40 [main] chmod (5536) ********************************************** 0 40 [main] chmod (5536) sigprocmask: 0 = sigprocmask (0, 0x1802BBC68, 0x0) 1479 1519 [main] chmod 5536 open_shared: name shared.5, n 5, shared 0x180030000 (wanted 0x180030000), h 0x6C, *m 6 124 1643 [main] chmod 5536 user_heap_info::init: heap base 0x600000000, heap top 0x600000000, heap size 0x20000000 (536870912) 125 1768 [main] chmod 5536 open_shared: name S-1-5-21-3514886939-1786686319-3519756147-1001.1, n 1, shared 0x180020000 (wanted 0x180020000), h 0x68, *m 6 165 1933 [main] chmod 5536 user_info::create: opening user shared for 'S-1-5-21-3514886939-1786686319-3519756147-1001' at 0x180020000 100 2033 [main] chmod 5536 user_info::create: user shared version AB1FCCE8 106 2139 [main] chmod 5536 fhandler_pipe::create: name \\.\pipe\cygwin-cbee506f76730215-5536-sigwait, size 176, mode PIPE_TYPE_MESSAGE 149 2288 [main] chmod 5536 fhandler_pipe::create: pipe read handle 0x80 70 2358 [main] chmod 5536 fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-cbee506f76730215-5536-sigwait 108 2466 [main] chmod 5536 fhandler_pipe::create: pipe write handle 0x84 74 2540 [main] chmod 5536 dll_crt0_0: finished dll_crt0_0 initialization 1348 3888 [sig] chmod 5536 wait_sig: entering ReadFile loop, my_readsig 0x80, my_sendsig 0x84 209 4097 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\Chris\test, no-keep-rel, no-add-slash) 126 4223 [main] chmod 5536 normalize_win32_path: C:\cygwin\home\Chris\test = normalize_win32_path (C:\cygwin\home\Chris\test) 77 4300 [main] chmod 5536 mount_info::conv_to_posix_path: /home/Chris/test = conv_to_posix_path (C:\cygwin\home\Chris\test) 476 4776 [main] chmod 5536 sigprocmask: 0 = sigprocmask (0, 0x600018128, 0x18013514B) 12712 17488 [main] chmod 5536 _cygwin_istext_for_stdio: fd 0: not open 106 17594 [main] chmod 5536 _cygwin_istext_for_stdio: fd 1: not open 99 17693 [main] chmod 5536 _cygwin_istext_for_stdio: fd 2: not open 318 18011 [main] chmod (5536) open_shared: name cygpid.5536, n 5536, shared 0x180010000 (wanted 0x180010000), h 0xA4, *m 2 30 18041 [main] ? (5536) time: 1399305706 = time(0x0) 0 18041 [main] chmod 5536 pinfo::thisproc: myself dwProcessId 5536 891 18932 [main] chmod 5536 environ_init: GetEnvironmentStrings returned 0x344E30 147 19079 [main] chmod 5536 environ_init: 0x6000284F0: ALLUSERSPROFILE=C:\ProgramData 162 19241 [main] chmod 5536 environ_init: 0x600028520: APPDATA=C:\Users\Chris J. Breisch\AppData\Roaming 85 19326 [main] chmod 5536 environ_init: 0x600028560: BASHRC_LOADED=true 78 19404 [main] chmod 5536 environ_init: 0x600028580: BASH_PROFILE_LOADED=true 132 19536 [main] chmod 5536 environ_init: 0x6000285B0: CLFS=/home/Chris/clfs 250 19786 [main] chmod 5536 environ_init: 0x6000285D0: CLIENTNAME=CBREISCH-WIN8 133 19919 [main] chmod 5536 environ_init: 0x600028600: COMMONPROGRAMFILES=C:\Program Files\Common Files 138 20057 [main] chmod 5536 environ_init: 0x600028640: COMPUTERNAME=WIN8-VM 116 20173 [main] chmod 5536 environ_init: 0x600028660: COMSPEC=C:\WINDOWS\system32\cmd.exe 111 20284 [main] chmod 5536 environ_init: 0x600028690: CVSROOT=:pserver:anoncvs@cygwin.com:/cvs/src 112 20396 [main] chmod 5536 environ_init: 0x6000286D0: CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files 112 20508 [main] chmod 5536 environ_init: 0x600028720: CommonProgramW6432=C:\Program Files\Common Files 113 20621 [main] chmod 5536 parse_options: glob (called func) 211 20832 [main] chmod 5536 parse_options: returning 61 20893 [main] chmod 5536 environ_init: 0x600028760: CYGWIN=noglob 134 21027 [main] chmod 5536 environ_init: 0x6000287A0: DISPLAY=:0 213 21240 [main] chmod 5536 environ_init: 0x6000287C0: EXECIGNORE=*.dll 120 21360 [main] chmod 5536 environ_init: 0x6000287E0: FP_NO_HOST_CHECK=NO 111 21471 [main] chmod 5536 getwinenv: can't set native for HOME= since no environ yet 73 21544 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\Chris, no-keep-rel, no-add-slash) 63 21607 [main] chmod 5536 normalize_win32_path: C:\cygwin\home\Chris = normalize_win32_path (C:\cygwin\home\Chris) 69 21676 [main] chmod 5536 mount_info::conv_to_posix_path: /home/Chris = conv_to_posix_path (C:\cygwin\home\Chris) 159 21835 [main] chmod 5536 win_env::add_cache: posix /home/Chris 64 21899 [main] chmod 5536 win_env::add_cache: native HOME=C:\cygwin\home\Chris 59 21958 [main] chmod 5536 posify_maybe: env var converted to HOME=/home/Chris 1082 23040 [main] chmod 5536 environ_init: 0x600028880: HOME=/home/Chris 1 23041 [main] chmod 5536 environ_init: 0x600028800: HOMEDRIVE=C: 0 23041 [main] chmod 5536 environ_init: 0x6000288A0: HOMEPATH=\Users\Chris J. Breisch 0 23041 [main] chmod 5536 environ_init: 0x6000288D0: HOSTNAME=WIN8-VM 0 23041 [main] chmod 5536 environ_init: 0x6000288F0: INFOPATH=/usr/local/info:/usr/share/info:/usr/info 0 23041 [main] chmod 5536 environ_init: 0x600028930: LESS=qesu 1042 24083 [main] chmod 5536 environ_init: 0x600028950: LIBRARY_PATH=/usr/local/lib 101 24184 [main] chmod 5536 environ_init: 0x600028980: LOCALAPPDATA=C:\Users\Chris J. Breisch\AppData\Local 93 24277 [main] chmod 5536 environ_init: 0x6000289C0: LOGONSERVER=\\MicrosoftAccount 133 24410 [main] chmod 5536 environ_init: 0x6000289F0: LS_COLORS=di=01;35 109 24519 [main] chmod 5536 environ_init: 0x600028A10: MANPATH=/usr/local/man:/usr/share/man:/usr/man:/usr/ssl/man 110 24629 [main] chmod 5536 environ_init: 0x600028A60: NUMBER_OF_PROCESSORS=1 90 24719 [main] chmod 5536 environ_init: 0x600028A80: OLDPWD=/home/Chris 88 24807 [main] chmod 5536 environ_init: 0x600028AA0: ORIGINAL_PATH=/win/c/WINDOWS/system32:/win/c/WINDOWS:/win/c/WINDOWS/System32/Wbem:/win/c/WINDOWS/System32/WindowsPowerShell/v1.0:/win/c/Program Files (x86)/Microsoft SQL Server/110/Tools/Binn/ManagementStudio:/win/c/Program Files (x86)/Microsoft SQL Server/110/Tools/Binn:/win/c/Program Files/Microsoft SQL Server/110/Tools/Binn:/win/c/Program Files (x86)/Microsoft SQL Server/110/DTS/Binn 84 24891 [main] chmod 5536 environ_init: 0x600028C30: OS=Windows_NT 149 25040 [main] chmod 5536 getwinenv: can't set native for PATH= since no environ yet 1 25041 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\Chris\bin, keep-rel, no-add-slash) 0 25041 [main] chmod 5536 normalize_win32_path: C:\cygwin\home\Chris\bin = normalize_win32_path (C:\cygwin\home\Chris\bin) 0 25041 [main] chmod 5536 mount_info::conv_to_posix_path: /home/Chris/bin = conv_to_posix_path (C:\cygwin\home\Chris\bin) 555 25596 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\AMD64\usr\local\bin, keep-rel, no-add-slash) 70 25666 [main] chmod 5536 normalize_win32_path: C:\cygwin\AMD64\usr\local\bin = normalize_win32_path (C:\cygwin\AMD64\usr\local\bin) 80 25746 [main] chmod 5536 mount_info::conv_to_posix_path: /usr/local/bin = conv_to_posix_path (C:\cygwin\AMD64\usr\local\bin) 114 25860 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\AMD64\bin, keep-rel, no-add-slash) 73 25933 [main] chmod 5536 normalize_win32_path: C:\cygwin\AMD64\bin = normalize_win32_path (C:\cygwin\AMD64\bin) 501 26434 [main] chmod 5536 mount_info::conv_to_posix_path: /usr/bin = conv_to_posix_path (C:\cygwin\AMD64\bin) 68 26502 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\Windows\system32, keep-rel, no-add-slash) 69 26571 [main] chmod 5536 normalize_win32_path: C:\Windows\system32 = normalize_win32_path (C:\Windows\system32) 46 26617 [main] chmod 5536 mount_info::conv_to_posix_path: /win/c/Windows/system32 = conv_to_posix_path (C:\Windows\system32) 129 26746 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\Windows, keep-rel, no-add-slash) 67 26813 [main] chmod 5536 normalize_win32_path: C:\Windows = normalize_win32_path (C:\Windows) 93 26906 [main] chmod 5536 mount_info::conv_to_posix_path: /win/c/Windows = conv_to_posix_path (C:\Windows) 53 26959 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\AMD64\usr\X11R6\bin, keep-rel, no-add-slash) 81 27040 [main] chmod 5536 normalize_win32_path: C:\cygwin\AMD64\usr\X11R6\bin = normalize_win32_path (C:\cygwin\AMD64\usr\X11R6\bin) 138 27178 [main] chmod 5536 mount_info::conv_to_posix_path: /usr/X11R6/bin = conv_to_posix_path (C:\cygwin\AMD64\usr\X11R6\bin) 61 27239 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\program files\microsoft sql server\110\tools\binn, keep-rel, no-add-slash) 46 27285 [main] chmod 5536 normalize_win32_path: C:\program files\microsoft sql server\110\tools\binn = normalize_win32_path (C:\program files\microsoft sql server\110\tools\binn) 50 27335 [main] chmod 5536 mount_info::conv_to_posix_path: /win/c/program files/microsoft sql server/110/tools/binn = conv_to_posix_path (C:\program files\microsoft sql server\110\tools\binn) 58 27393 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\AMD64\usr\sbin, keep-rel, no-add-slash) 91 27484 [main] chmod 5536 normalize_win32_path: C:\cygwin\AMD64\usr\sbin = normalize_win32_path (C:\cygwin\AMD64\usr\sbin) 60 27544 [main] chmod 5536 mount_info::conv_to_posix_path: /usr/sbin = conv_to_posix_path (C:\cygwin\AMD64\usr\sbin) 159 27703 [main] chmod 5536 win_env::add_cache: posix /home/Chris/bin:/usr/local/bin:/usr/bin:/win/c/Windows/system32:/win/c/Windows:/usr/X11R6/bin:/win/c/program files/microsoft sql server/110/tools/binn:/usr/sbin 58 27761 [main] chmod 5536 win_env::add_cache: native PATH=C:\cygwin\home\Chris\bin;C:\cygwin\AMD64\usr\local\bin;C:\cygwin\AMD64\bin;C:\Windows\system32;C:\Windows;C:\cygwin\AMD64\usr\X11R6\bin;C:\program files\microsoft sql server\110\tools\binn;C:\cygwin\AMD64\usr\sbin 56 27817 [main] chmod 5536 posify_maybe: env var converted to PATH=/home/Chris/bin:/usr/local/bin:/usr/bin:/win/c/Windows/system32:/win/c/Windows:/usr/X11R6/bin:/win/c/program files/microsoft sql server/110/tools/binn:/usr/sbin 111 27928 [main] chmod 5536 environ_init: 0x600038EF0: PATH=/home/Chris/bin:/usr/local/bin:/usr/bin:/win/c/Windows/system32:/win/c/Windows:/usr/X11R6/bin:/win/c/program files/microsoft sql server/110/tools/binn:/usr/sbin 101 28029 [main] chmod 5536 environ_init: 0x600028C50: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC 88 28117 [main] chmod 5536 environ_init: 0x600028CA0: PP22_EXE4J_JAVA_HOME=C:\Program Files (x86)\Java\jre7 84 28201 [main] chmod 5536 environ_init: 0x600028CE0: PRINTER=HP LaserJet P2035n (redirected 2) 125 28326 [main] chmod 5536 environ_init: 0x600038FA0: PROCESSOR_ARCHITECTURE=AMD64 104 28430 [main] chmod 5536 environ_init: 0x600038FD0: PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 30 Stepping 5, GenuineIntel 142 28572 [main] chmod 5536 environ_init: 0x600028D20: PROCESSOR_LEVEL=6 160 28732 [main] chmod 5536 environ_init: 0x600039030: PROCESSOR_REVISION=1e05 147 28879 [main] chmod 5536 environ_init: 0x600039060: PROFILEREAD=true 136 29015 [main] chmod 5536 environ_init: 0x600039080: PROGRAMFILES=C:\Program Files 122 29137 [main] chmod 5536 environ_init: 0x6000390B0: PROMPT_COMMAND=echo -ne "\033]0;${USER}@${HOSTNAME} (${PROCESSOR_ARCHITECTURE})\007" 93 29230 [main] chmod 5536 environ_init: 0x600039110: PS1=\[\e[1;32m\]\u@\h [ \[\e[0m\]\w\[\e[1;32m\] ]$ \[\e[0m\] 86 29316 [main] chmod 5536 environ_init: 0x600039160: PSModulePath=C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\;C:\Program Files (x86)\Microsoft SQL Server\110\Tools\PowerShell\Modules\ 89 29405 [main] chmod 5536 environ_init: 0x600039200: PUBLIC=C:\Users\Public 87 29492 [main] chmod 5536 environ_init: 0x600039220: PWD=/home/Chris/test 85 29577 [main] chmod 5536 environ_init: 0x600039240: ProgramData=C:\ProgramData 134 29711 [main] chmod 5536 environ_init: 0x600039270: ProgramFiles(x86)=C:\Program Files (x86) 95 29806 [main] chmod 5536 environ_init: 0x6000392B0: ProgramW6432=C:\Program Files 147 29953 [main] chmod 5536 environ_init: 0x6000392E0: SESSIONNAME=RDP-Tcp#5 191 30144 [main] chmod 5536 environ_init: 0x600039300: SHELL=/bin/bash 122 30266 [main] chmod 5536 environ_init: 0x600039320: SHLVL=1 155 30421 [main] chmod 5536 environ_init: 0x600039340: SYSTEMDRIVE=C: 105 30526 [main] chmod 5536 environ_init: 0x600039360: SYSTEMROOT=C:\WINDOWS 82 30608 [main] chmod 5536 getwinenv: can't set native for TEMP= since no environ yet 49 30657 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\AMD64\tmp, no-keep-rel, no-add-slash) 45 30702 [main] chmod 5536 normalize_win32_path: C:\cygwin\AMD64\tmp = normalize_win32_path (C:\cygwin\AMD64\tmp) 50 30752 [main] chmod 5536 mount_info::conv_to_posix_path: /tmp = conv_to_posix_path (C:\cygwin\AMD64\tmp) 111 30863 [main] chmod 5536 win_env::add_cache: posix /tmp 46 30909 [main] chmod 5536 win_env::add_cache: native TEMP=C:\cygwin\AMD64\tmp 56 30965 [main] chmod 5536 posify_maybe: env var converted to TEMP=/tmp 185 31150 [main] chmod 5536 environ_init: 0x600039400: TEMP=/tmp 110 31260 [main] chmod 5536 environ_init: 0x600039380: TERM=xterm 86 31346 [main] chmod 5536 getwinenv: can't set native for TMP= since no environ yet 44 31390 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\AMD64\tmp, no-keep-rel, no-add-slash) 49 31439 [main] chmod 5536 normalize_win32_path: C:\cygwin\AMD64\tmp = normalize_win32_path (C:\cygwin\AMD64\tmp) 70 31509 [main] chmod 5536 mount_info::conv_to_posix_path: /tmp = conv_to_posix_path (C:\cygwin\AMD64\tmp) 219 31728 [main] chmod 5536 win_env::add_cache: posix /tmp 66 31794 [main] chmod 5536 win_env::add_cache: native TMP=C:\cygwin\AMD64\tmp 66 31860 [main] chmod 5536 posify_maybe: env var converted to TMP=/tmp 166 32026 [main] chmod 5536 environ_init: 0x600039490: TMP=/tmp 110 32136 [main] chmod 5536 environ_init: 0x600039420: TZ=America/New_York 104 32240 [main] chmod 5536 environ_init: 0x6000394B0: USER=Chris 102 32342 [main] chmod 5536 environ_init: 0x6000394D0: USERDOMAIN=WIN8-VM 103 32445 [main] chmod 5536 environ_init: 0x6000394F0: USERDOMAIN_ROAMINGPROFILE=WIN8-VM 102 32547 [main] chmod 5536 environ_init: 0x600039520: USERNAME=Chris 104 32651 [main] chmod 5536 environ_init: 0x600039540: USERPROFILE=C:\Users\Chris J. Breisch 207 32858 [main] chmod 5536 environ_init: 0x600039570: VISUAL=/usr/bin/vi 105 32963 [main] chmod 5536 environ_init: 0x600039590: WINDIR=C:\WINDOWS 209 33172 [main] chmod 5536 environ_init: 0x6000395B0: _=/usr/bin/strace 92 33264 [main] chmod 5536 pinfo_init: Set nice to 0 64 33328 [main] chmod 5536 pinfo_init: pid 5536, pgid 5536, process_state 0x41 66 33394 [main] chmod 5536 App version: 1007.18, api: 0.263 58 33452 [main] chmod 5536 DLL version: 1007.29, api: 0.272 64 33516 [main] chmod 5536 DLL build: 2014-04-07 13:46 75 33591 [main] chmod 5536 dtable::extend: size 32, fds 0x1802DDFC0 729 34320 [main] chmod 5536 pwdgrp::load: \etc\passwd curr_lines 12 89 34409 [main] chmod 5536 pwdgrp::load: \etc\passwd load succeeded 668 35077 [main] chmod 5536 pwdgrp::load: \etc\group curr_lines 23 72 35149 [main] chmod 5536 pwdgrp::load: \etc\group load succeeded 63 35212 [main] chmod 5536 internal_getlogin: NtSetInformationToken (TokenPrimaryGroup), 0xC000005B 53 35265 [main] chmod 5536 cygheap_user::ontherange: what 2, pw 0x600039C30 45 35310 [main] chmod 5536 cygheap_user::ontherange: HOME is already in the environment /home/Chris 252 35562 [main] chmod 5536 build_argv: argv[0] = 'chmod' 111 35673 [main] chmod 5536 build_argv: argv[1] = '400' 56 35729 [main] chmod 5536 build_argv: argv[2] = 'bar' 44 35773 [main] chmod 5536 build_argv: argc 3 189 35962 [main] chmod 5536 build_fh_pc: created an archetype (0x1802DE420) for /dev/pty0(136/0) 261 36223 [main] chmod 5536 build_fh_pc: fh 0x1802DE1B0, dev 00880000 96 36319 [main] chmod 5536 fhandler_pipe::create: name \\.\pipe\cygwin-cbee506f76730215-pty0-from-master, size 131072, mode PIPE_TYPE_MESSAGE 150 36469 [main] chmod 5536 fhandler_pipe::create: pipe busy 82 36551 [main] chmod 5536 tty::exists: exists 1 151 36702 [main] chmod 5536 alloc_sd: uid 1001, gid 513, attribute 0x2190 65 36767 [main] chmod 5536 cygsid::debug_print: alloc_sd: owner SID = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) 70 36837 [main] chmod 5536 cygsid::debug_print: alloc_sd: group SID = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) 55 36892 [main] chmod 5536 alloc_sd: ACL-Size: 88 296 37188 [main] chmod 5536 alloc_sd: Created SD-Size: 164 78 37266 [main] chmod 5536 fhandler_pty_slave::open: (440): pty output_mutex (0xA8): waiting -1 ms 74 37340 [main] chmod 5536 fhandler_pty_slave::open: (440): pty output_mutex: acquired 76 37416 [main] chmod 5536 tty::create_inuse: cygtty.slave_alive.0 0xB4 121 37537 [main] chmod 5536 fhandler_pty_slave::open: (443): pty output_mutex(0xA8) released 142 37679 [main] chmod 5536 open_shared: name cygpid.652, n 652, shared 0x20000 (wanted 0x0), h 0xB8, *m 6 67 37746 [main] chmod 5536 fhandler_pty_slave::open: dup handles directly since I'm the owner 78 37824 [main] chmod 5536 fhandler_pty_slave::open: duplicated from_master 0x22C->0xB8 from pty_owner 52 37876 [main] chmod 5536 fhandler_pty_slave::open: duplicated to_master 0x23C->0xC0 from pty_owner 88 37964 [main] chmod 5536 fhandler_console::need_invisible: invisible_console 0 107 38071 [main] chmod 5536 fhandler_base::open_with_arch: line 474: /dev/pty0<0x1802DE420> usecount + 1 = 1 572 38643 [main] chmod 5536 fhandler_base::set_flags: flags 0x10002, supplied_bin 0x0 70 38713 [main] chmod 5536 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x10000 70 38783 [main] chmod 5536 fhandler_base::set_flags: filemode set to binary 73 38856 [main] chmod 5536 _pinfo::set_ctty: old no ctty, ctty device number 0xFFFFFFFF, tc.ntty device number 0x880000 flags & O_NOCTTY 0x0 53 38909 [main] chmod 5536 _pinfo::set_ctty: cygheap->ctty 0x0, archetype 0x1802DE420 43 38952 [main] chmod 5536 _pinfo::set_ctty: ctty was NULL 58 39010 [main] chmod 5536 _pinfo::set_ctty: line 482: /dev/pty0<0x1802DE420> usecount + 1 = 2 83 39093 [main] chmod 5536 _pinfo::set_ctty: /dev/pty0 ctty, usecount 2 719 39812 [main] chmod 5536 _pinfo::set_ctty: attaching ctty /dev/pty0 sid 5536, pid 5536, pgid 5536, tty->pgid 6112, tty->sid 3996 77 39889 [main] chmod 5536 _pinfo::set_ctty: cygheap->ctty now 0x1802DE420, archetype 0x1802DE420 68 39957 [main] chmod 5536 fhandler_pty_slave::open_setup: /dev/pty0 opened, usecount 2 86 40043 [main] chmod 5536 fhandler_base::set_flags: flags 0x10002, supplied_bin 0x0 65 40108 [main] chmod 5536 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x10000 46 40154 [main] chmod 5536 fhandler_base::set_flags: filemode set to binary 47 40201 [main] chmod 5536 _pinfo::set_ctty: old ctty /dev/pty0, ctty device number 0x880000, tc.ntty device number 0x880000 flags & O_NOCTTY 0x0 88 40289 [main] chmod 5536 _pinfo::set_ctty: attaching ctty /dev/pty0 sid 3996, pid 5536, pgid 6112, tty->pgid 6112, tty->sid 3996 53 40342 [main] chmod 5536 _pinfo::set_ctty: cygheap->ctty now 0x1802DE420, archetype 0x1802DE420 41 40383 [main] chmod 5536 fhandler_pty_slave::open_setup: /dev/pty0 opened, usecount 2 3118 43501 [main] chmod 5536 handle_to_fn: current match 'C:' = '\Device\HarddiskVolume1' 413 43914 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\Chris\test\strace.out, no-keep-rel, no-add-slash) 182 44096 [main] chmod 5536 normalize_win32_path: C:\cygwin\home\Chris\test\strace.out = normalize_win32_path (C:\cygwin\home\Chris\test\strace.out) 65 44161 [main] chmod 5536 mount_info::conv_to_posix_path: /home/Chris/test/strace.out = conv_to_posix_path (C:\cygwin\home\Chris\test\strace.out) 69 44230 [main] chmod 5536 handle_to_fn: derived path 'C:\cygwin\home\Chris\test\strace.out', posix '/home/Chris/test/strace.out' 68 44298 [main] chmod 5536 normalize_posix_path: src /home/Chris/test/strace.out 69 44367 [main] chmod 5536 normalize_posix_path: /home/Chris/test/strace.out = normalize_posix_path (/home/Chris/test/strace.out) 62 44429 [main] chmod 5536 mount_info::conv_to_win32_path: conv_to_win32_path (/home/Chris/test/strace.out) 59 44488 [main] chmod 5536 set_flags: flags: binary (0x2) 113 44601 [main] chmod 5536 mount_info::conv_to_win32_path: src_path /home/Chris/test/strace.out, dst C:\cygwin\home\Chris\test\strace.out, flags 0x2, rc 0 115 44716 [main] chmod 5536 symlink_info::check: 0x0 = NtCreateFile (\??\C:\cygwin\home\Chris\test\strace.out) 96 44812 [main] chmod 5536 symlink_info::check: not a symlink 3967 48779 [main] chmod 5536 symlink_info::check: 0 = symlink.check(C:\cygwin\home\Chris\test\strace.out, 0x239750) (0x2) 126 48905 [main] chmod 5536 path_conv::check: this->path(C:\cygwin\home\Chris\test\strace.out), has_acls(1) 71 48976 [main] chmod 5536 build_fh_pc: fh 0x1802DE790, dev 000000C3 88 49064 [main] chmod 5536 fhandler_base::set_flags: flags 0x10001, supplied_bin 0x0 75 49139 [main] chmod 5536 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x10000 60 49199 [main] chmod 5536 fhandler_base::set_flags: filemode set to binary 66 49265 [main] chmod 5536 fhandler_base::init: created new fhandler_base for handle 0x240, bin 1 2219 51484 [main] chmod 5536 handle_to_fn: current match 'C:' = '\Device\HarddiskVolume1' 312 51796 [main] chmod 5536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\Chris\test\strace.out, no-keep-rel, no-add-slash) 65 51861 [main] chmod 5536 normalize_win32_path: C:\cygwin\home\Chris\test\strace.out = normalize_win32_path (C:\cygwin\home\Chris\test\strace.out) 48 51909 [main] chmod 5536 mount_info::conv_to_posix_path: /home/Chris/test/strace.out = conv_to_posix_path (C:\cygwin\home\Chris\test\strace.out) 50 51959 [main] chmod 5536 handle_to_fn: derived path 'C:\cygwin\home\Chris\test\strace.out', posix '/home/Chris/test/strace.out' 263 52222 [main] chmod 5536 normalize_posix_path: src /home/Chris/test/strace.out 95 52317 [main] chmod 5536 normalize_posix_path: /home/Chris/test/strace.out = normalize_posix_path (/home/Chris/test/strace.out) 67 52384 [main] chmod 5536 mount_info::conv_to_win32_path: conv_to_win32_path (/home/Chris/test/strace.out) 53 52437 [main] chmod 5536 set_flags: flags: binary (0x2) 45 52482 [main] chmod 5536 mount_info::conv_to_win32_path: src_path /home/Chris/test/strace.out, dst C:\cygwin\home\Chris\test\strace.out, flags 0x2, rc 0 93 52575 [main] chmod 5536 symlink_info::check: 0x0 = NtCreateFile (\??\C:\cygwin\home\Chris\test\strace.out) 70 52645 [main] chmod 5536 symlink_info::check: not a symlink 4903 57548 [main] chmod 5536 symlink_info::check: 0 = symlink.check(C:\cygwin\home\Chris\test\strace.out, 0x239750) (0x2) 141 57689 [main] chmod 5536 path_conv::check: this->path(C:\cygwin\home\Chris\test\strace.out), has_acls(1) 68 57757 [main] chmod 5536 build_fh_pc: fh 0x1802DEA30, dev 000000C3 52 57809 [main] chmod 5536 fhandler_base::set_flags: flags 0x10001, supplied_bin 0x0 52 57861 [main] chmod 5536 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x10000 56 57917 [main] chmod 5536 fhandler_base::set_flags: filemode set to binary 113 58030 [main] chmod 5536 fhandler_base::init: created new fhandler_base for handle 0x228, bin 1 140 58170 [main] chmod 5536 __set_errno: void dll_crt0_1(void*):999 setting errno 0 518 58688 [main] chmod 5536 __get_lcid_from_locale: LCID=0x0000 181 58869 [main] chmod 5536 __get_lcid_from_locale: LCID=0x0000 118 58987 [main] chmod 5536 __get_lcid_from_locale: LCID=0x0000 251 59238 [main] chmod 5536 __get_lcid_from_locale: LCID=0x0000 157 59395 [main] chmod 5536 __get_lcid_from_locale: LCID=0x0000 1206 60601 [main] chmod 5536 stat64: entering 65 60666 [main] chmod 5536 normalize_posix_path: src bar 52 60718 [main] chmod 5536 cwdstuff::get: posix /home/Chris/test 61 60779 [main] chmod 5536 cwdstuff::get: (/home/Chris/test) = cwdstuff::get (0x600000010, 32768, 1, 0), errno 0 98 60877 [main] chmod 5536 normalize_posix_path: /home/Chris/test/bar = normalize_posix_path (bar) 83 60960 [main] chmod 5536 mount_info::conv_to_win32_path: conv_to_win32_path (/home/Chris/test/bar) 45 61005 [main] chmod 5536 set_flags: flags: binary (0x2) 32 61037 [main] chmod 5536 mount_info::conv_to_win32_path: src_path /home/Chris/test/bar, dst C:\cygwin\home\Chris\test\bar, flags 0x2, rc 0 4 61041 [main] chmod 5536 symlink_info::check: 0x0 = NtCreateFile (\??\C:\cygwin\home\Chris\test\bar) 2 61043 [main] chmod 5536 symlink_info::check: not a symlink 0 61043 [main] chmod 5536 symlink_info::check: 0 = symlink.check(C:\cygwin\home\Chris\test\bar, 0x239680) (0x400002) 0 61043 [main] chmod 5536 path_conv::check: this->path(C:\cygwin\home\Chris\test\bar), has_acls(1) 0 61043 [main] chmod 5536 build_fh_pc: fh 0x1802DECD0, dev 000000C3 0 61043 [main] chmod 5536 stat_worker: (\??\C:\cygwin\home\Chris\test\bar, 0x600043E60, 0x1802DECD0), file_attributes 32 0 61043 [main] chmod 5536 cygpsid::debug_print: get_sids_info: owner SID = S-1-5-21-3514886939-1786686319-3519756147-1001 1123 62166 [main] chmod 5536 cygpsid::debug_print: get_sids_info: group SID = S-1-5-21-3514886939-1786686319-3519756147-1001 70 62236 [main] chmod 5536 get_info_from_sd: ACL 0x120, uid 1001, gid 513 226 62462 [main] chmod 5536 fhandler_base::fstat_helper: 0 = fstat (\??\C:\cygwin\home\Chris\test\bar, 0x600043E60) st_size=0, st_mode=0x8120, st_ino=6192449487651093st_atim=53679BCD.2937D718 st_ctim=5367B418.904190C st_mtim=53679BCD.2937D718 st_birthtim=53679BCD.291EA1F8 233 62695 [main] chmod 5536 stat_worker: 0 = (\??\C:\cygwin\home\Chris\test\bar,0x600043E60) 347 63042 [main] chmod 5536 normalize_posix_path: src /home/Chris/test/bar 1 63043 [main] chmod 5536 normalize_posix_path: /home/Chris/test/bar = normalize_posix_path (/home/Chris/test/bar) 0 63043 [main] chmod 5536 mount_info::conv_to_win32_path: conv_to_win32_path (/home/Chris/test/bar) 448 63491 [main] chmod 5536 set_flags: flags: binary (0x2) 54 63545 [main] chmod 5536 mount_info::conv_to_win32_path: src_path /home/Chris/test/bar, dst C:\cygwin\home\Chris\test\bar, flags 0x2, rc 0 86 63631 [main] chmod 5536 symlink_info::check: 0x0 = NtCreateFile (\??\C:\cygwin\home\Chris\test\bar) 72 63703 [main] chmod 5536 symlink_info::check: not a symlink 124 63827 [main] chmod 5536 symlink_info::check: 0 = symlink.check(C:\cygwin\home\Chris\test\bar, 0x239560) (0x2) 71 63898 [main] chmod 5536 path_conv::check: this->path(C:\cygwin\home\Chris\test\bar), has_acls(1) 199 64097 [main] chmod 5536 build_fh_pc: fh 0x1802DECD0, dev 000000C3 64 64161 [main] chmod 5536 fhandler_base::open: (\??\C:\cygwin\home\Chris\test\bar, 0x110000) 209 64370 [main] chmod 5536 fhandler_base::set_flags: flags 0x110000, supplied_bin 0x10000 60 64430 [main] chmod 5536 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x10000 52 64482 [main] chmod 5536 fhandler_base::set_flags: filemode set to binary 44 64526 [main] chmod 5536 fhandler_base::open: 0x0 = NtCreateFile (0xE0, 0x60100, \??\C:\cygwin\home\Chris\test\bar, io, NULL, 0x0, 0x7, 0x1, 0x4000, NULL, 0) 59 64585 [main] chmod 5536 fhandler_base::open: 1 = fhandler_base::open(\??\C:\cygwin\home\Chris\test\bar, 0x110000) 100 64685 [main] chmod 5536 fhandler_base::open_fs: 1 = fhandler_disk_file::open(\??\C:\cygwin\home\Chris\test\bar, 0x10000) 106 64791 [main] chmod 5536 alloc_sd: uid 4294967295, gid 4294967295, attribute 0x100 54 64845 [main] chmod 5536 cygsid::debug_print: alloc_sd: owner SID = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) 80 64925 [main] chmod 5536 cygsid::debug_print: alloc_sd: group SID = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) 55 64980 [main] chmod 5536 alloc_sd: ACL-Size: 84 171 65151 [main] chmod 5536 alloc_sd: Created SD-Size: 160 293 65444 [main] chmod 5536 set_file_attribute: 0 = set_file_attribute(\??\C:\cygwin\home\Chris\test\bar, -1, -1, 0x100) 86 65530 [main] chmod 5536 fhandler_base::close: closing '/home/Chris/test/bar' handle 0xE0 233 65763 [main] chmod 5536 chmod: 0 = chmod(/home/Chris/test/bar, 0400) 775 66538 [main] chmod 5536 close: close(1) 81 66619 [main] chmod 5536 fhandler_base::close: closing '/home/Chris/test/strace.out' handle 0x240 86 66705 [main] chmod 5536 close: 0 = close(1) 1006 67711 [main] chmod 5536 close: close(2) 46 67757 [main] chmod 5536 fhandler_base::close: closing '/home/Chris/test/strace.out' handle 0x228 52 67809 [main] chmod 5536 close: 0 = close(2) 565 68374 [main] chmod 5536 do_exit: do_exit (0), exit_state 1 45 68419 [main] chmod 5536 void: 0x0 = signal (20, 0x1) 49 68468 [main] chmod 5536 void: 0x0 = signal (1, 0x1) 43 68511 [main] chmod 5536 void: 0x0 = signal (2, 0x1) 47 68558 [main] chmod 5536 void: 0x0 = signal (3, 0x1) 47 68605 [main] chmod 5536 fhandler_base::close_with_arch: line 1140: /dev/pty0<0x1802DE420> usecount + -1 = 1 51 68656 [main] chmod 5536 fhandler_base::close_with_arch: not closing archetype 57 68713 [main] chmod 5536 init_cygheap::close_ctty: closing cygheap->ctty 0x1802DE420 89 68802 [main] chmod 5536 fhandler_base::close_with_arch: closing passed in archetype 0x0, usecount 0 53 68855 [main] chmod 5536 fhandler_pty_slave::cleanup: /dev/pty0 closed, usecount 0 48 68903 [main] chmod 5536 fhandler_pty_slave::close: closing last open /dev/pty0 handle 98 69001 [main] chmod 5536 fhandler_console::free_console: freed console, res 1 106 69107 [main] chmod 5536 fhandler_pty_common::close: pty0 <0xB8,0xC0> closing 88 69195 [main] chmod 5536 dtable::delete_archetype: deleting element 0 for /dev/pty0(136/0) 61 69256 [main] chmod 5536 getpid: 5536 = getpid() 84 69340 [main] chmod 5536 proc_terminate: nprocs 0 73 69413 [main] chmod 5536 proc_terminate: leaving 74 69487 [main] chmod 5536 pinfo::exit: Calling ExitProcess n 0x0, exitcode 0x0 [-- Attachment #3: Type: text/plain, Size: 218 bytes --] -- 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] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 16:17 ` Chris J. Breisch @ 2014-05-05 16:57 ` Corinna Vinschen 2014-05-05 18:52 ` Robert Pendell 2014-05-05 18:56 ` Chris J. Breisch 0 siblings, 2 replies; 42+ messages in thread From: Corinna Vinschen @ 2014-05-05 16:57 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 3319 bytes --] On May 5 12:17, Chris J. Breisch wrote: > Corinna Vinschen wrote: > >On May 5 11:23, Chris J. Breisch wrote: > >>In both cases, I am logging on to the machine with a "Microsoft > >>Account": http://www.microsoft.com/en-us/account/default.aspx > > > >Hmm, maybe that's the problem. This "Microsoft Account" stuff might > >influence how the underlying OS handles permissions. I would never > >touch this stuff ;) > > I don't blame you. And I don't think you can use them on a machine > that's a member of a domain, but I could be mistaken there. They're > local accounts, but definitely with a twist. I was pleasantly > surprised that ssh didn't choke on them, but I didn't really suspect > it as a root cause for file permission issues, or I would have > mentioned that in my very first message. > > > > >For testing you could try to create a normal local account, add it to > >/etc/passwd and run the above under this account. If it behaves > >differently (correct, that is), it's a something weird with these MS > >accounts. But then again, I wouldn't know how to "fix" this, other > >than to suggest to use a normal account instead. > > Bingo. I had just such an account already. It works as expected, > i.e. correctly. > > Could we "fix" it by allowing the user to set their default group? > As I said in my original message, changing the group from None to > Users in /etc/passwd solved my problems. That's exactly how you do it, unless you're already using the new SAM/AD changes from the Cygwin snapshots, in which case you can override this in SAM or AD as well. > Of course, if we don't really understand these accounts, then we > don't know why that solved my problem, or if the same thing would > work for someone else. Hmmm. Never mind. > > >Nah, at this point we really don't know why this happens on your machine > >and it could easily be somebody elses fault. > > > >An strace of `chmod 400 bar' might sched some light on this issue, but I > >have a gut feeling the underlying WIndows call will not even return an > >error code... > > Attached. Your gut seems to be working today... There *is* something weird here. Look at this: > 151 36702 [main] chmod 5536 alloc_sd: uid 1001, gid 513, attribute 0x2190 > 65 36767 [main] chmod 5536 cygsid::debug_print: alloc_sd: owner SID = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) > 70 36837 [main] chmod 5536 cygsid::debug_print: alloc_sd: group SID = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) alloc_sd (the underlying function creating a security descriptor) gets a uid 1001 and gid 513 as input, as usual. But the owner *and* group SIDs of the file's existing security descriptor is S-1-5-21-3514886939-1786686319-3519756147-1001, the SID of your user account. Why is your user account the primary group of the file, even though your user token definitely has "None" (513) as its primary group? How did it get there? Is that something enforced by the "Microsoft accounts", perhaps? I just had a look into the Local Security Policy settings, and I can't see any related setting. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 16:57 ` Corinna Vinschen @ 2014-05-05 18:52 ` Robert Pendell 2014-05-06 13:02 ` Corinna Vinschen 2014-05-05 18:56 ` Chris J. Breisch 1 sibling, 1 reply; 42+ messages in thread From: Robert Pendell @ 2014-05-05 18:52 UTC (permalink / raw) To: cygwin On Mon, May 5, 2014 at 12:57 PM, Corinna Vinschen wrote: > On May 5 12:17, Chris J. Breisch wrote: >> Corinna Vinschen wrote: >> >On May 5 11:23, Chris J. Breisch wrote: >> >>In both cases, I am logging on to the machine with a "Microsoft >> >>Account": http://www.microsoft.com/en-us/account/default.aspx >> > >> >Hmm, maybe that's the problem. This "Microsoft Account" stuff might >> >influence how the underlying OS handles permissions. I would never >> >touch this stuff ;) >> >> I don't blame you. And I don't think you can use them on a machine >> that's a member of a domain, but I could be mistaken there. They're >> local accounts, but definitely with a twist. I was pleasantly >> surprised that ssh didn't choke on them, but I didn't really suspect >> it as a root cause for file permission issues, or I would have >> mentioned that in my very first message. >> >> > >> >For testing you could try to create a normal local account, add it to >> >/etc/passwd and run the above under this account. If it behaves >> >differently (correct, that is), it's a something weird with these MS >> >accounts. But then again, I wouldn't know how to "fix" this, other >> >than to suggest to use a normal account instead. >> >> Bingo. I had just such an account already. It works as expected, >> i.e. correctly. >> >> Could we "fix" it by allowing the user to set their default group? >> As I said in my original message, changing the group from None to >> Users in /etc/passwd solved my problems. > > That's exactly how you do it, unless you're already using the new SAM/AD > changes from the Cygwin snapshots, in which case you can override this > in SAM or AD as well. > >> Of course, if we don't really understand these accounts, then we >> don't know why that solved my problem, or if the same thing would >> work for someone else. Hmmm. Never mind. >> >> >Nah, at this point we really don't know why this happens on your machine >> >and it could easily be somebody elses fault. >> > >> >An strace of `chmod 400 bar' might sched some light on this issue, but I >> >have a gut feeling the underlying WIndows call will not even return an >> >error code... >> >> Attached. Your gut seems to be working today... > > There *is* something weird here. Look at this: > >> 151 36702 [main] chmod 5536 alloc_sd: uid 1001, gid 513, attribute 0x2190 >> 65 36767 [main] chmod 5536 cygsid::debug_print: alloc_sd: owner SID = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) >> 70 36837 [main] chmod 5536 cygsid::debug_print: alloc_sd: group SID = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) > > alloc_sd (the underlying function creating a security descriptor) gets > a uid 1001 and gid 513 as input, as usual. But the owner *and* group > SIDs of the file's existing security descriptor is > S-1-5-21-3514886939-1786686319-3519756147-1001, the SID of your user > account. > > Why is your user account the primary group of the file, even though > your user token definitely has "None" (513) as its primary group? > How did it get there? > > Is that something enforced by the "Microsoft accounts", perhaps? > > I just had a look into the Local Security Policy settings, and I can't > see any related setting. > > > Corinna > I just saw this thread. I'm running Windows 8.1 Update 1 and I'm using a Microsoft Account as login. I'm seeing the same behavior on my machine as well with Cygwin64. I'm open to any tests that you would like me to do as well. -- 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] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 18:52 ` Robert Pendell @ 2014-05-06 13:02 ` Corinna Vinschen 0 siblings, 0 replies; 42+ messages in thread From: Corinna Vinschen @ 2014-05-06 13:02 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1501 bytes --] On May 5 14:52, Robert Pendell wrote: > On Mon, May 5, 2014 at 12:57 PM, Corinna Vinschen wrote: > > alloc_sd (the underlying function creating a security descriptor) gets > > a uid 1001 and gid 513 as input, as usual. But the owner *and* group > > SIDs of the file's existing security descriptor is > > S-1-5-21-3514886939-1786686319-3519756147-1001, the SID of your user > > account. > > > > Why is your user account the primary group of the file, even though > > your user token definitely has "None" (513) as its primary group? > > How did it get there? > > > > Is that something enforced by the "Microsoft accounts", perhaps? > > > > I just had a look into the Local Security Policy settings, and I can't > > see any related setting. > > > > > > Corinna > > > > I just saw this thread. I'm running Windows 8.1 Update 1 and I'm > using a Microsoft Account as login. I'm seeing the same behavior on > my machine as well with Cygwin64. I'm open to any tests that you > would like me to do as well. Thanks for the offer. Please see my mails I just sent in reply to Chris' mails: http://cygwin.com/ml/cygwin/2014-05/msg00083.html http://cygwin.com/ml/cygwin/2014-05/msg00084.html if you'd like to test the latest snapshot and follow my suggestions in terms of the primary group... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 16:57 ` Corinna Vinschen 2014-05-05 18:52 ` Robert Pendell @ 2014-05-05 18:56 ` Chris J. Breisch 2014-05-05 19:44 ` Larry Hall (Cygwin) 2014-05-06 12:52 ` Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) Corinna Vinschen 1 sibling, 2 replies; 42+ messages in thread From: Chris J. Breisch @ 2014-05-05 18:56 UTC (permalink / raw) To: cygwin Corinna Vinschen wrote: > On May 5 12:17, Chris J. Breisch wrote: >> Corinna Vinschen wrote: >>> An strace of `chmod 400 bar' might sched some light on this issue, but I >>> have a gut feeling the underlying WIndows call will not even return an >>> error code... >> Attached. Your gut seems to be working today... > > There *is* something weird here. Look at this: > >> 151 36702 [main] chmod 5536 alloc_sd: uid 1001, gid 513, attribute 0x2190 >> 65 36767 [main] chmod 5536 cygsid::debug_print: alloc_sd: owner SID = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) >> 70 36837 [main] chmod 5536 cygsid::debug_print: alloc_sd: group SID = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) > > alloc_sd (the underlying function creating a security descriptor) gets > a uid 1001 and gid 513 as input, as usual. But the owner *and* group > SIDs of the file's existing security descriptor is > S-1-5-21-3514886939-1786686319-3519756147-1001, the SID of your user > account. > > Why is your user account the primary group of the file, even though > your user token definitely has "None" (513) as its primary group? > How did it get there? > I don't have a clue. You're the expert. :) The ACLs are a little different between the Microsoft Account and the regular local account. But, if anything, it's the regular one that looks odd to me. Microsoft Account: $ icacls bar bar WIN8-VM\Chris:(R,D,WDAC,WO,WA) Everyone:(Rc,S,RA) NT AUTHORITY\Authenticated Users:(M) Local account: $ icacls foo foo WIN8-VM\cjb:(R,D,WDAC,WO,WA) WIN8-VM\None:(Rc,S,RA) Everyone:(Rc,S,RA) Why does the local account have None permissions, and not Authenticated Users? > Is that something enforced by the "Microsoft accounts", perhaps? > > I just had a look into the Local Security Policy settings, and I can't > see any related setting. > I have no clue. If you want to throw some more debugging code into a snapshot, I'll happily test it. I'll do whatever you want, even shut up and go away. :) I should point out that all of this is with Cygwin64. From what we've discovered so far, it seems likely that I'll get the same behavior under Cygwin32. But I'll verify that tonight when I get home. -- Chris J. Breisch -- 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] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 18:56 ` Chris J. Breisch @ 2014-05-05 19:44 ` Larry Hall (Cygwin) 2014-05-05 21:57 ` Chris J. Breisch 2014-05-06 12:52 ` Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) Corinna Vinschen 1 sibling, 1 reply; 42+ messages in thread From: Larry Hall (Cygwin) @ 2014-05-05 19:44 UTC (permalink / raw) To: cygwin On 05/05/2014 02:56 PM, Chris J. Breisch wrote: > Corinna Vinschen wrote: >> On May 5 12:17, Chris J. Breisch wrote: >>> Corinna Vinschen wrote: >>>> An strace of `chmod 400 bar' might sched some light on this issue, but I >>>> have a gut feeling the underlying WIndows call will not even return an >>>> error code... >>> Attached. Your gut seems to be working today... >> >> There *is* something weird here. Look at this: >> >>> 151 36702 [main] chmod 5536 alloc_sd: uid 1001, gid 513, attribute >>> 0x2190 >>> 65 36767 [main] chmod 5536 cygsid::debug_print: alloc_sd: owner SID >>> = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) >>> 70 36837 [main] chmod 5536 cygsid::debug_print: alloc_sd: group SID >>> = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) >> >> alloc_sd (the underlying function creating a security descriptor) gets >> a uid 1001 and gid 513 as input, as usual. But the owner *and* group >> SIDs of the file's existing security descriptor is >> S-1-5-21-3514886939-1786686319-3519756147-1001, the SID of your user >> account. >> >> Why is your user account the primary group of the file, even though >> your user token definitely has "None" (513) as its primary group? >> How did it get there? >> > I don't have a clue. You're the expert. :) > > The ACLs are a little different between the Microsoft Account and the > regular local account. But, if anything, it's the regular one that looks odd > to me. > > Microsoft Account: > $ icacls bar > bar WIN8-VM\Chris:(R,D,WDAC,WO,WA) > Everyone:(Rc,S,RA) > NT AUTHORITY\Authenticated Users:(M) > > > Local account: > $ icacls foo > foo WIN8-VM\cjb:(R,D,WDAC,WO,WA) > WIN8-VM\None:(Rc,S,RA) > Everyone:(Rc,S,RA) > > Why does the local account have None permissions, and not Authenticated Users? POSIX permissions are user, group, other. For your local account, that's user = cib, group = None, other = Everyone. Of course, I'm assuming that foo was made using Cygwin utilities... I'm wondering if we're getting the user id as the group for the MS Account because there is no group id. Chris, what does 'id' for each of these accounts look like and is the group id (assuming they are different that the user id) in there? -- Larry _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 19:44 ` Larry Hall (Cygwin) @ 2014-05-05 21:57 ` Chris J. Breisch 2014-05-05 22:07 ` Chris J. Breisch 2014-05-05 22:09 ` Larry Hall (Cygwin) 0 siblings, 2 replies; 42+ messages in thread From: Chris J. Breisch @ 2014-05-05 21:57 UTC (permalink / raw) To: cygwin Larry Hall (Cygwin) wrote: > On 05/05/2014 02:56 PM, Chris J. Breisch wrote: >> Corinna Vinschen wrote: >>> On May 5 12:17, Chris J. Breisch wrote: >>>> Corinna Vinschen wrote: >>>>> An strace of `chmod 400 bar' might sched some light on this issue, >>>>> but I >>>>> have a gut feeling the underlying WIndows call will not even return an >>>>> error code... >>>> Attached. Your gut seems to be working today... >>> >>> There *is* something weird here. Look at this: >>> >>>> 151 36702 [main] chmod 5536 alloc_sd: uid 1001, gid 513, attribute >>>> 0x2190 >>>> 65 36767 [main] chmod 5536 cygsid::debug_print: alloc_sd: owner SID >>>> = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) >>>> 70 36837 [main] chmod 5536 cygsid::debug_print: alloc_sd: group SID >>>> = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) >>> >>> alloc_sd (the underlying function creating a security descriptor) gets >>> a uid 1001 and gid 513 as input, as usual. But the owner *and* group >>> SIDs of the file's existing security descriptor is >>> S-1-5-21-3514886939-1786686319-3519756147-1001, the SID of your user >>> account. >>> >>> Why is your user account the primary group of the file, even though >>> your user token definitely has "None" (513) as its primary group? >>> How did it get there? >>> >> I don't have a clue. You're the expert. :) >> > > I'm wondering if we're getting the user id as the group for the MS > Account because there is no group id. Chris, what does 'id' for > each of these accounts look like and is the group id (assuming they > are different that the user id) in there? > > Well, I hope I'm not comparing apples and oranges, because now I'm at home. However, I have duplicated the scenario and results on this machine. It was actually where I noticed it first. id produces expected results: MS account: $ id uid=1001(Chris) gid=513(None) groups=513(None),545(Users),1003(HomeUsers) Local account: $ id uid=1007(cjb) gid=513(None) groups=513(None),545(Users),1003(HomeUsers) Actually, it's not quite what I expected. Chris is in the Administrators group, and that's not shown. $ net user Chris User name Chris Full Name Chris Breisch Comment User's comment Country/region code 001 (United States) Account active Yes Account expires Never [snip PW stuff for Cygwin filter] Workstations allowed All Logon script User profile Home directory Last logon 5/1/2014 8:39:44 PM Logon hours allowed All Local Group Memberships *Administrators *HomeUsers *Users Global Group memberships *None The command completed successfully. $ net user cjb User name cjb Full Name cjb Comment User's comment Country/region code 000 (System Default) Account active Yes Account expires Never [snip] Workstations allowed All Logon script User profile Home directory Last logon 5/5/2014 5:40:39 PM Logon hours allowed All Local Group Memberships *HomeUsers *Users Global Group memberships *None The command completed successfully. -- Chris J. Breisch -- 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] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 21:57 ` Chris J. Breisch @ 2014-05-05 22:07 ` Chris J. Breisch 2014-05-05 22:29 ` Larry Hall (Cygwin) 2014-05-05 22:09 ` Larry Hall (Cygwin) 1 sibling, 1 reply; 42+ messages in thread From: Chris J. Breisch @ 2014-05-05 22:07 UTC (permalink / raw) To: cygwin Chris J. Breisch wrote: > Larry Hall (Cygwin) wrote: >> On 05/05/2014 02:56 PM, Chris J. Breisch wrote: >>> Corinna Vinschen wrote: >>>> On May 5 12:17, Chris J. Breisch wrote: >>>>> Corinna Vinschen wrote: >>>>>> An strace of `chmod 400 bar' might sched some light on this issue, >>>>>> but I >>>>>> have a gut feeling the underlying WIndows call will not even >>>>>> return an >>>>>> error code... >>>>> Attached. Your gut seems to be working today... >>>> >>>> There *is* something weird here. Look at this: >>>> >>>>> 151 36702 [main] chmod 5536 alloc_sd: uid 1001, gid 513, attribute >>>>> 0x2190 >>>>> 65 36767 [main] chmod 5536 cygsid::debug_print: alloc_sd: owner SID >>>>> = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) >>>>> 70 36837 [main] chmod 5536 cygsid::debug_print: alloc_sd: group SID >>>>> = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) >>>> >>>> alloc_sd (the underlying function creating a security descriptor) gets >>>> a uid 1001 and gid 513 as input, as usual. But the owner *and* group >>>> SIDs of the file's existing security descriptor is >>>> S-1-5-21-3514886939-1786686319-3519756147-1001, the SID of your user >>>> account. >>>> >>>> Why is your user account the primary group of the file, even though >>>> your user token definitely has "None" (513) as its primary group? >>>> How did it get there? >>>> >>> I don't have a clue. You're the expert. :) >>> >> >> I'm wondering if we're getting the user id as the group for the MS >> Account because there is no group id. Chris, what does 'id' for >> each of these accounts look like and is the group id (assuming they >> are different that the user id) in there? >> >> > > Well, I hope I'm not comparing apples and oranges, because now I'm at > home. However, I have duplicated the scenario and results on this > machine. It was actually where I noticed it first. > > id produces expected results: > > MS account: > $ id > uid=1001(Chris) gid=513(None) groups=513(None),545(Users),1003(HomeUsers) > > Local account: > $ id > uid=1007(cjb) gid=513(None) groups=513(None),545(Users),1003(HomeUsers) > > Actually, it's not quite what I expected. Chris is in the Administrators > group, and that's not shown. > > $ net user Chris > User name Chris > Full Name Chris Breisch > Comment > User's comment > Country/region code 001 (United States) > Account active Yes > Account expires Never > > [snip PW stuff for Cygwin filter] > > Workstations allowed All > Logon script > User profile > Home directory > Last logon 5/1/2014 8:39:44 PM > > Logon hours allowed All > > Local Group Memberships *Administrators *HomeUsers > *Users > Global Group memberships *None > The command completed successfully. > > $ net user cjb > User name cjb > Full Name cjb > Comment > User's comment > Country/region code 000 (System Default) > Account active Yes > Account expires Never > > [snip] > > Workstations allowed All > Logon script > User profile > Home directory > Last logon 5/5/2014 5:40:39 PM > > Logon hours allowed All > > Local Group Memberships *HomeUsers *Users > Global Group memberships *None > The command completed successfully. > > Hmmm, just noticed something in /etc/group: Chris J. Breisch:S-1-5-21-3514886939-1786686319-3519756147-1001:11001: and on another machine where I can reproduce this: Chris:S-1-5-21-1055441198-2882714470-4103286779-1001:11001: Oddly, mkgroup -l does not produce this line on either machine, so I'm not sure where it came from. In both cases, the SID for the group is the same as the my user's SID. -- Chris J. Breisch -- 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] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 22:07 ` Chris J. Breisch @ 2014-05-05 22:29 ` Larry Hall (Cygwin) 2014-05-05 22:39 ` Chris J. Breisch 0 siblings, 1 reply; 42+ messages in thread From: Larry Hall (Cygwin) @ 2014-05-05 22:29 UTC (permalink / raw) To: cygwin On 05/05/2014 06:07 PM, Chris J. Breisch wrote: > Chris J. Breisch wrote: >> Larry Hall (Cygwin) wrote: >>> On 05/05/2014 02:56 PM, Chris J. Breisch wrote: >>>> Corinna Vinschen wrote: >>>>> On May 5 12:17, Chris J. Breisch wrote: >>>>>> Corinna Vinschen wrote: >>>>>>> An strace of `chmod 400 bar' might sched some light on this issue, >>>>>>> but I >>>>>>> have a gut feeling the underlying WIndows call will not even >>>>>>> return an >>>>>>> error code... >>>>>> Attached. Your gut seems to be working today... >>>>> >>>>> There *is* something weird here. Look at this: >>>>> >>>>>> 151 36702 [main] chmod 5536 alloc_sd: uid 1001, gid 513, attribute >>>>>> 0x2190 >>>>>> 65 36767 [main] chmod 5536 cygsid::debug_print: alloc_sd: owner SID >>>>>> = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) >>>>>> 70 36837 [main] chmod 5536 cygsid::debug_print: alloc_sd: group SID >>>>>> = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) >>>>> >>>>> alloc_sd (the underlying function creating a security descriptor) gets >>>>> a uid 1001 and gid 513 as input, as usual. But the owner *and* group >>>>> SIDs of the file's existing security descriptor is >>>>> S-1-5-21-3514886939-1786686319-3519756147-1001, the SID of your user >>>>> account. >>>>> >>>>> Why is your user account the primary group of the file, even though >>>>> your user token definitely has "None" (513) as its primary group? >>>>> How did it get there? >>>>> >>>> I don't have a clue. You're the expert. :) >>>> >>> >>> I'm wondering if we're getting the user id as the group for the MS >>> Account because there is no group id. Chris, what does 'id' for >>> each of these accounts look like and is the group id (assuming they >>> are different that the user id) in there? >>> >>> >> >> Well, I hope I'm not comparing apples and oranges, because now I'm at >> home. However, I have duplicated the scenario and results on this >> machine. It was actually where I noticed it first. >> >> id produces expected results: >> >> MS account: >> $ id >> uid=1001(Chris) gid=513(None) groups=513(None),545(Users),1003(HomeUsers) >> >> Local account: >> $ id >> uid=1007(cjb) gid=513(None) groups=513(None),545(Users),1003(HomeUsers) >> >> Actually, it's not quite what I expected. Chris is in the Administrators >> group, and that's not shown. >> >> $ net user Chris >> User name Chris >> Full Name Chris Breisch >> Comment >> User's comment >> Country/region code 001 (United States) >> Account active Yes >> Account expires Never >> >> [snip PW stuff for Cygwin filter] >> >> Workstations allowed All >> Logon script >> User profile >> Home directory >> Last logon 5/1/2014 8:39:44 PM >> >> Logon hours allowed All >> >> Local Group Memberships *Administrators *HomeUsers >> *Users >> Global Group memberships *None >> The command completed successfully. >> >> $ net user cjb >> User name cjb >> Full Name cjb >> Comment >> User's comment >> Country/region code 000 (System Default) >> Account active Yes >> Account expires Never >> >> [snip] >> >> Workstations allowed All >> Logon script >> User profile >> Home directory >> Last logon 5/5/2014 5:40:39 PM >> >> Logon hours allowed All >> >> Local Group Memberships *HomeUsers *Users >> Global Group memberships *None >> The command completed successfully. >> >> > Hmmm, just noticed something in /etc/group: > > Chris J. Breisch:S-1-5-21-3514886939-1786686319-3519756147-1001:11001: > > and on another machine where I can reproduce this: > Chris:S-1-5-21-1055441198-2882714470-4103286779-1001:11001: > > Oddly, mkgroup -l does not produce this line on either machine, so I'm not > sure where it came from. In both cases, the SID for the group is the same as > the my user's SID. Is 513/None in the /etc/group file too or is it missing? -- Larry _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 22:29 ` Larry Hall (Cygwin) @ 2014-05-05 22:39 ` Chris J. Breisch 2014-05-06 0:43 ` Larry Hall (Cygwin) 0 siblings, 1 reply; 42+ messages in thread From: Chris J. Breisch @ 2014-05-05 22:39 UTC (permalink / raw) To: cygwin Larry Hall (Cygwin) wrote: > On 05/05/2014 06:07 PM, Chris J. Breisch wrote: >> Hmmm, just noticed something in /etc/group: >> >> Chris J. Breisch:S-1-5-21-3514886939-1786686319-3519756147-1001:11001: >> >> and on another machine where I can reproduce this: >> Chris:S-1-5-21-1055441198-2882714470-4103286779-1001:11001: >> >> Oddly, mkgroup -l does not produce this line on either machine, so I'm >> not >> sure where it came from. In both cases, the SID for the group is the >> same as >> the my user's SID. > > Is 513/None in the /etc/group file too or is it missing? > > 513/None is in /etc/group. It's the next to last line. The line above is the last line and apparently comes from some prior invocation of 'mkgroup -c'. I never knew until this moment that there was a 'mkgroup -c', so I didn't do it. :) I am guessing that's part of Cygwin's postinstall? -- Chris J. Breisch -- 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] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 22:39 ` Chris J. Breisch @ 2014-05-06 0:43 ` Larry Hall (Cygwin) 2014-05-06 12:23 ` Chris J. Breisch 0 siblings, 1 reply; 42+ messages in thread From: Larry Hall (Cygwin) @ 2014-05-06 0:43 UTC (permalink / raw) To: cygwin On 05/05/2014 06:39 PM, Chris J. Breisch wrote: > Larry Hall (Cygwin) wrote: >> On 05/05/2014 06:07 PM, Chris J. Breisch wrote: >>> Hmmm, just noticed something in /etc/group: >>> >>> Chris J. Breisch:S-1-5-21-3514886939-1786686319-3519756147-1001:11001: >>> >>> and on another machine where I can reproduce this: >>> Chris:S-1-5-21-1055441198-2882714470-4103286779-1001:11001: >>> >>> Oddly, mkgroup -l does not produce this line on either machine, so I'm >>> not >>> sure where it came from. In both cases, the SID for the group is the >>> same as >>> the my user's SID. >> >> Is 513/None in the /etc/group file too or is it missing? >> >> > > 513/None is in /etc/group. It's the next to last line. The line above is the > last line and apparently comes from some prior invocation of 'mkgroup -c'. I > never knew until this moment that there was a 'mkgroup -c', so I didn't do > it. :) I am guessing that's part of Cygwin's postinstall? Yes. See /etc/postinstall/000-cygwin-post-install.sh* I'm not quite sure why your user and its ID ended up in your group file though. I don't see it in mine and invoking 'mkgroup -l -c' doesn't enumerate it. For the moment, you can try removing this line and see if it helps with your problem. -- Larry _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-06 0:43 ` Larry Hall (Cygwin) @ 2014-05-06 12:23 ` Chris J. Breisch 0 siblings, 0 replies; 42+ messages in thread From: Chris J. Breisch @ 2014-05-06 12:23 UTC (permalink / raw) To: cygwin Larry Hall (Cygwin) wrote: > On 05/05/2014 06:39 PM, Chris J. Breisch wrote: >> 513/None is in /etc/group. It's the next to last line. The line above >> is the >> last line and apparently comes from some prior invocation of 'mkgroup >> -c'. I >> never knew until this moment that there was a 'mkgroup -c', so I >> didn't do >> it. :) I am guessing that's part of Cygwin's postinstall? > > Yes. See /etc/postinstall/000-cygwin-post-install.sh* > > I'm not quite sure why your user and its ID ended up in your group file > though. I don't see it in mine and invoking 'mkgroup -l -c' doesn't > enumerate it. For the moment, you can try removing this line and > see if it helps with your problem. > No, no changes at all. I bet that you're not surprised though. -- Chris J. Breisch -- 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] 42+ messages in thread
* Re: Problem with "None" Group on Non-Domain Members 2014-05-05 21:57 ` Chris J. Breisch 2014-05-05 22:07 ` Chris J. Breisch @ 2014-05-05 22:09 ` Larry Hall (Cygwin) 1 sibling, 0 replies; 42+ messages in thread From: Larry Hall (Cygwin) @ 2014-05-05 22:09 UTC (permalink / raw) To: cygwin On 05/05/2014 05:57 PM, Chris J. Breisch wrote: > Larry Hall (Cygwin) wrote: >> On 05/05/2014 02:56 PM, Chris J. Breisch wrote: >>> Corinna Vinschen wrote: >>>> On May 5 12:17, Chris J. Breisch wrote: >>>>> Corinna Vinschen wrote: >>>>>> An strace of `chmod 400 bar' might sched some light on this issue, >>>>>> but I >>>>>> have a gut feeling the underlying WIndows call will not even return an >>>>>> error code... >>>>> Attached. Your gut seems to be working today... >>>> >>>> There *is* something weird here. Look at this: >>>> >>>>> 151 36702 [main] chmod 5536 alloc_sd: uid 1001, gid 513, attribute >>>>> 0x2190 >>>>> 65 36767 [main] chmod 5536 cygsid::debug_print: alloc_sd: owner SID >>>>> = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) >>>>> 70 36837 [main] chmod 5536 cygsid::debug_print: alloc_sd: group SID >>>>> = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) >>>> >>>> alloc_sd (the underlying function creating a security descriptor) gets >>>> a uid 1001 and gid 513 as input, as usual. But the owner *and* group >>>> SIDs of the file's existing security descriptor is >>>> S-1-5-21-3514886939-1786686319-3519756147-1001, the SID of your user >>>> account. >>>> >>>> Why is your user account the primary group of the file, even though >>>> your user token definitely has "None" (513) as its primary group? >>>> How did it get there? >>>> >>> I don't have a clue. You're the expert. :) >>> >> >> I'm wondering if we're getting the user id as the group for the MS >> Account because there is no group id. Chris, what does 'id' for >> each of these accounts look like and is the group id (assuming they >> are different that the user id) in there? >> >> > > Well, I hope I'm not comparing apples and oranges, because now I'm at home. > However, I have duplicated the scenario and results on this machine. It was > actually where I noticed it first. > > id produces expected results: > > MS account: > $ id > uid=1001(Chris) gid=513(None) groups=513(None),545(Users),1003(HomeUsers) > > Local account: > $ id > uid=1007(cjb) gid=513(None) groups=513(None),545(Users),1003(HomeUsers) <snip> OK, thanks. That answers my question but doesn't give any insight into the original issue. :-( -- Larry _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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] 42+ messages in thread
* Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-05 18:56 ` Chris J. Breisch 2014-05-05 19:44 ` Larry Hall (Cygwin) @ 2014-05-06 12:52 ` Corinna Vinschen 2014-05-06 12:55 ` Corinna Vinschen ` (2 more replies) 1 sibling, 3 replies; 42+ messages in thread From: Corinna Vinschen @ 2014-05-06 12:52 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 6325 bytes --] On May 5 14:56, Chris J. Breisch wrote: > Corinna Vinschen wrote: > >alloc_sd (the underlying function creating a security descriptor) gets > >a uid 1001 and gid 513 as input, as usual. But the owner *and* group > >SIDs of the file's existing security descriptor is > >S-1-5-21-3514886939-1786686319-3519756147-1001, the SID of your user > >account. > > > >Why is your user account the primary group of the file, even though > >your user token definitely has "None" (513) as its primary group? > >How did it get there? > > > I don't have a clue. You're the expert. :) > > The ACLs are a little different between the Microsoft Account and > the regular local account. But, if anything, it's the regular one > that looks odd to me. > > Microsoft Account: > $ icacls bar > bar WIN8-VM\Chris:(R,D,WDAC,WO,WA) > Everyone:(Rc,S,RA) > NT AUTHORITY\Authenticated Users:(M) > > > Local account: > $ icacls foo > foo WIN8-VM\cjb:(R,D,WDAC,WO,WA) > WIN8-VM\None:(Rc,S,RA) > Everyone:(Rc,S,RA) No, the local account permissions look entirely correct... > Why does the local account have None permissions, and not > Authenticated Users? ...because that's how the POSIX permissions are generated. They always consist of an entry for your user, your primary group, and the Everyone group as the Windows equivalent for the POSIX "other" permissions. But, here's the deal. I eventually gave up and created a Microsoft Account on my W8.1 machine. And this was definitely the right thing to do, for a couple of reasons: - For a start, it uncovered a case-sensitivity bug in my new SAM/AD account code. - In my case `id' showed clearly that in my user token the primary group is set to my user account itself. I'm using my new SAM/AD code, so I can see what happens if there are no /etc/passwd and /etc/group files in the way. - This explains why your user account shows up in /etc/group. `mkpasswd -c' creates the group info from your user token, and the primary group in your user token is your own user account. - The reason that you *seem* to have "None" as primary group is a result of historical laziness: mkpasswd simply sets the primary gid to 513 for all local accounts, since that's what it always was so far. - The reason that setting your primary group to "None" doesn't really work (and thus, neither do file group permissions) is the fact that the "None" group is no longer in the user token's group list. For kicks, if you call `net user <yourusername>' it still prints Global Group memberships *None - The reason that setting your primary group to "Users" works fine is the fact that it *is* in the user token's group list. - One account in the user token's group list is a special SID for a user(!) account which apparently connects your local account with the Microsoft Account. Here's the output from Windows' own `whoami' tool: MicrosoftAccount\testuser@foobar.de User S-1-11-96-3623454863-58364-18864-2661722203-1597581903-2673650909-3269597714-2381787221-1144632321-4110357092 Mandatory group, Enabled by default, Enabled group The problem here is the length of the SID. So far the Cygwin code assumes that a SID has a maximum number of 8 subauthorities. This is based on the fact that the Win32 routine to generate a SID allows a maximum of 8 subauthorities, so it was a relatively safe assumption. Not so, anymore. The subauthorities are the numbers starting at the 96. If I count correctly we now have a SID with 11 subauthorities. This is, of course, my fault. In reality there's a macro in the Windows headers called SID_MAX_SUB_AUTHORITIES, which is set to 15. But so far there were never more than 6 subauthorities, so I never had a reason to look :| As a sidenote, the SIDs of the Microsoft Accounts are undocumented and no matching values exist even in the latest Microsoft VC++ header files... - The maximum length of a netbios domain name is defined as DNLEN in lmcons.h. DNLEN is 15. The new domain name "MicrosoftAccount" has a length of 16. Cygwin uses buffers based on DNLEN :-P That's the state for now. I patched Cygwin to be able to handle all of the above, but I didn't touch the primary group in the user token yet. So, if you download the today's developer snapshot from http://cygwin.com/snapshots/, you get at least a somewhat sane behaviour: - If you have no passwd/group files (or set /etc/nsswitch.conf to passwd: db group: db so that you just rely on the new SAM/AD code in Cygwin, you get a primary group == your user account. The output of `id' reflects what I wrote above. You will see a group called MicrosoftAccount\<your email address> as part of the supplementary group list. - If you still use your current /etc/passwd, you will still have the "None" weirdness perhaps, because the group with gid 513 is simply not in your user token, and there's nothing Cygwin can do about that. - If you want to utilize Cygwin's capability to override your primary group, you have two choices: - Download the complete cygwin-inst-20140506.tar.xz for your platform (x86/x86_64) and use the new mkpasswd and mkgroup tools in there to generate new /etc/passwd and /etc/group files. Then override your primary group with the value 545, just like before. - Alternatively, change the primary group in the Windows SAM, as described in the document attached to this mail. It's the latest version of the preliminary documentation of the new account handling in Cygwin. See the chapter "Cygwin user names, home dirs, login shells". Other than that, I'm open to discuss the necessity(?) to override the primary group by default. But, in fact, I'm not sure this really makes sense. Linux systems default to creating a user-specific group account and using that as the user's primary group for years. The Windows Account technique isn't quite as nice, but admittedly, it does its job just as well. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-06 12:52 ` Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) Corinna Vinschen @ 2014-05-06 12:55 ` Corinna Vinschen 2014-05-06 13:01 ` Corinna Vinschen 2014-05-06 17:01 ` Chris J. Breisch 2 siblings, 0 replies; 42+ messages in thread From: Corinna Vinschen @ 2014-05-06 12:55 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 612 bytes --] On May 6 14:52, Corinna Vinschen wrote: > - Alternatively, change the primary group in the Windows SAM, as > described in the document attached to this mail. It's the latest > version of the preliminary documentation of the new account handling > in Cygwin. See the chapter "Cygwin user names, home dirs, login > shells". Ok, next time I should probably attach the document to the original mail. Sorry, attached now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #1.2: pwdgrp-doc --] [-- Type: text/plain, Size: 32149 bytes --] ======= History ======= For as long as Cygwin has existed, it has stored user and group information in /etc/passwd and /etc/group files. Under the assumption that these files would never be too large, the first process in a process tree, as well as every execing process within the tree would parse them into structures in memory. Thus every Cygwin process would contain an expanded copy of the full information from /etc/passwd and /etc/group. This approach has a few downsides. One of them is that the idea to have always small files is flawed. Another one is that reading the entire file is most of the time entirely useless, since most processes only need information on their own user and the primary group. Last but not least, the passwd and group files have to be maintained separately from the already existing Windows user databases, the local SAM and Active Directory. On the other hand, we have to have a mapping between Windows SIDs and POSIX uid/gid values (see [1]), so we rely on some mechanism to convert SIDs to uid/gid values and vice versa. Microsoft "Services for UNIX" (SFU) (which are unfortunately deprecated since Windows 8/Server 2012) never used passwd/group files. Rather, SFU used a fixed, computational mapping between SIDs and POSIX uid/gid. It allows to generate uid/gid values from SIDs and vice versa. The mechanism is documented, albeit in a confusing way and spread over multiple MSDN articles. The Cygwin approach clones the mapping, with just tiny differences for backward compatibility. ================= How does it work? ================= The following description assumes you're comfortable with the concept of Windows SIDs and RIDs. For a brief introduction, please read [1]. Cygwin's new mapping between SIDs and uid/gid values works in two ways. - Read /etc/passwd and /etc/group files, like before, mainly for backward compatibility. - If no files are present, or if an entry is missing in the files, ask Windows. At least, that's the default behaviour now. It will be configurable using a file /etc/nsswitch.conf, which is discussed in a later section. Let's explore the default for now. If files are present, they will be scanned on demand as soon as a mapping from SIDs to uid/gid or account names is required. The new mechanism will never read the entire file into memory, but only scan for the requested entry and cache this one in memory[2]. If no entry is found, or no passwd or group file was present, Cygwin will ask the OS. Note: If the first process in a Cygwin process tree determines that no /etc/passwd or /etc/group file is present, no other process in the entire process tree will try to read the files later on. This is done for self-preservation. It's rather bad if the uid or gid of a user changes during the lifetime of a process tree. For the same reason, if you delete the /etc/passwd or /etc/group file, this will be ignored. The passwd and group records read from the files will persist in memory until either a new /etc/passwd or /etc/group files is created, or you exit all processes in the current process tree. See the note in the section on /etc/nsswitch.conf for some comprehensive examples. So if we've drawn a blank reading the files, we're going to ask the OS. First thing, we ask the local machine for the SID or the username. The OS functions LookupAccountSid and LookupAccountName[3] are pretty intelligent. They have all the stuff built in to ask for any account of the local machine, the Active Directory domain of the machine, the Global Catalog of the forest of the domain, as well as any trusted domain of our forest for the information. One OS call and we're practically done... Except, the calls only return the mapping between SID, account name and the account's domain. We don't have a mapping to POSIX uid/gid and we're missing information on the user's home dir and login shell. Let's discuss the SID<=>uid/gid mapping first. Here's how it works. - Well-known SIDs in the NT_AUTHORITY domain of the S-1-5-RID type, or aliases of the S-1-5-32-RID type are mapped to the uid/gid value RID[4]. For an overview of well-known SIDs, see [5]. Examples: "SYSTEM" S-1-5-18 <=> uid/gid: 18 "Users" S-1-5-32-545 <=> uid/gid: 545 - Other well-known SIDs in the NT_AUTHORITY domain (S-1-5-X-RID): S-1-5-X-RID <=> uid/gid: 0x1000 * X + RID Example: "NTLM Authentication" S-1-5-64-10 <=> uid/gid: 0x4000A == 262154 - Other well-known SIDs: S-1-X-Y <=> uid/gid: 0x10000 + 0x100 * X + Y Example: "LOCAL" S-1-2-0 <=> uid/gid: 0x10200 == 66048 "Creator Group" S-1-3-1 <=> uid/gid: 0x10301 == 66305 - Logon SIDs: The own LogonSid is converted to the fixed uid 0xfff == 4095 and named "CurrentSession". Any other LogonSid is converted to the fixed uid 0xffe == 4094 and named "OtherSession". - Mandatory Labels: S-1-16-RID <=> uid/gid: 0x60000 + RID Example: "Medium Mandatory Level" S-1-16-8192 <=> uid/gid: 0x62000 == 401408 - Accounts from the local machine's user DB (SAM): S-1-5-21-X-Y-Z-RID <=> 0x30000 + RID Example: "Administrator" S-1-5-X-Y-Z-500 <=> uid/gid: 0x301f4 == 197108 - Accounts from the machine's primary domain: S-1-5-21-X-Y-Z-RID <=> 0x100000 + RID Example: "Domain Users" S-1-5-X-Y-Z-513 <=> 0x100201 == 1049089 - Accounts from a trusted domain of the machine's primary domain: S-1-5-21-X-Y-Z-RID <=> trustPosixOffset(domain) + RID "trustPosixOffset"? This needs a bit of explanation. This value exists in Windows domains already since before Active Directory days. What happens is this. If you create a domain trust between two domains, a trustedDomain entry will be added to both databases. It describes how *this* domain trusts the *other* domain. One attribute of a trust is a 32 bit value called "trustPosixOffset" For each new trust, trustPosixOffset will get some automatic value. In recent AD domain implementations, the first trusted domain will get trustPosixOffset set to 0x80000000. Following domains will get lower values. Unfortunately the domain admins are allowed to set the trustPosixOffset value for each trusted domain to some arbitrary 32 bit value, no matter what the other trustPosixOffsets are seet to, thus allowing any kind of collisions between the trustPosixOffsets of domains. That's not exactly helpful, but as the user of this value, we have to *trust* the domain admins to set trustPosixOffset to sensible values, or to keep it at the system chosen values. So, for the first (or only) trusted domain of your domain, the automatic offset is 0x80000000. An example for a user of that trusted domain is: S-1-5-X-Y-Z-1234 <=> uid/gid 0x800004d2 == 2147484882 There's only one problem with this approach. Assuming you're running in the context of a local SAM user on a domain member machine. Local users don't have the right to fetch this kind of domain information from the DC, they'll get permission denied. In this case Cygwin will fake a, mostly, sensible trustPosixOffset value for this session. - Local accounts from another machine in the network: There's no SID<=>uid/gid mapping implemented for this case. The problem is, there's no way to generate a bijective mapping. There's no central place which keeps an analogue value of the trustPosixOffset, and there's the additional problem that the LookupAccountSid and LookupAccountName functions cannnot resolve the SIDs, unless they know the name of the machine this SID comes from. And even then it will probably suffer a "Permission denied" when trying to ask the machine for its local account. SFU just prints the account RID in this case, Cygwin maps the account to the fake accounts "Unknown+User"/"Unknown+Group" with uid/gid -1. Now we have a semi-bijective mapping between SIDs and POSIX uid/gid values, but, given that we have potentially users and groups in different domains having the same name, how do we uniquely differ between them by name? Well, we can do that by making their names unique in a per-machine way. Dependent on the domain membership of the account, and dependent of the machine being a domain member or not, the user and group names will be generated using a domain prefix and a separator character between domain and account name. The default separator character is the plus sign, '+', as in SFU. - Well-known SIDs will have the separator character prepended: "+SYSTEM", "+LOCAL", "+Medium Mandatory Level", ... - If the machine is no domain member machine, only local accounts can be resolved into names, so for ease of use, just the account names are used as Cygwin user/group names: "corinna", "bigfoot", "None", ... - If the machine is a domain member machine, all accounts from the primary domain of the machine are mapped to Cygwin names without domain prefix: "corinna", "bigfoot", "Domain Users", ... while accounts from other domains are prepended by their domain: "DOMAIN1+corinna", "DOMAIN2+bigfoot", "DOMAIN3+Domain Users", ... - Local machine accounts of a domain member machine get a Cygwin user name the same way as accounts from another domain: The local machine name gets prepended: "MYMACHINE+corinna", "MYMACHINE+bigfoot", "MYMACHINE+None", ... - If LookupAccountSid fails, Cygwin checks the accounts against the known trusted domains. If the account is from one of the trusted domains, an artificial account name is created. It consists of the domain name, and a special name created from the account RID: "MY_DOM+User(1234)", "MY_DOM+Group(5678)" Otherwise we know nothing about this SID, so it will be mapped to the fake accounts "Unknown+User"/"Unknown+Group" with uid/gid -1. ======= Caching ======= The information fetched from file or the Windows account database is cached by the process. The cached information is inherited by child processes. While usually working fine, this has some drawbacks. Consider a shell calling `id'. `id' fetches all group information from the current token and caches them. Unfortunately `id' doesn't start any child processes, so the information is lost as soon as `id' exits. But there's another caching mechanism available. If cygserver is running it will provide passwd and group entry caching for all processes in a Cygwin process tree, which first process has been started after cygserver. So, if you start a Cygwin Terminal and cygserver is running at the time, mintty, the shell, and all child processes will use cygserver caching. If you start a Cygwin Terminal and cygserver is not running a the time, none of the processes started inside this terminal window will use cygserver caching. The advantage of cygserver caching is that it's system-wide and, as long as cygserver is running, unforgetful. Every Cygwin process on the system will have the cygserver cache at its service. Additionally, all information requested from cygserver once, will be cached inside the process itself and, again, propagated to child processes. ========================================== Cygwin user names, home dirs, login shells ========================================== Obviously, if you don't maintain passwd and group files, you need to have a way to maintain the other fields of a passwd entry as well. Three things come to mind: - You want to use a Cygwin username different from your Windows username. Note: This is only supported via /etc/passwd and /etc/group files. A Cygwin username maintained in the Windows user databases would require very costly (read: slow) seach operations. - You want a home dir different from the default /home/$USER. - You want to specify a different login shell than /bin/bash. How this is done depends on your account being a domain account or a local account. Let's start with the default. Assuming your Windows account name is "bigfoot" and your domain is "MY_DOM". Your default passwd entry in absence of anything I'll describe below looks like this: bigfoot:*:<uid>:<gid>:U-MY_DOM\bigfoot,S-1-5-....:/home/bigfoot:/bin/bash or, if your account is from a different domain than the primary domain of the machine: MY_DOM+bigfoot:*:<uid>:<gid>:U-MY_DOM\bigfoot,S-1-5-....:/home/bigfoot:/bin/bash Yes, the default homedir is still /home/bigfoot. If your account is a domain account: Either create an /etc/passwd and/or /etc/group file with entries for your account and use that, just as before. Or, Cygwin will utilize the posixAccount/posixGroup attributes per RFC 2307[6]. These attributes are by default available in Active Directory since Windows Server 2003 R2. They are "not set", unless utilized by the (deprecated since Server 2012 R2) Active Directory "Server for NIS" feature. The user attributes utilized by Cygwin are: unixHomeDirectory If set, will be used as Cygwin home directory. loginShell If set, will be used as Cygwin login shell. gecos Content will be added to the pw_gecos field. uidNumber See next section. The group attributes utilized by Cygwin are: gidNumber See next section. Apart from power shell scripting or inventing new CLI tools, these attributes can be changed using the "Attribute Editor" tab in the user properties dialog of the "Active Directory Users and Computers" MMC snap-in. Alternatively, if the "Server for NIS" administration feature has been installed, there will be a "UNIX Attributes" tab which contains the required fields, except for the gecos field, which isn't really important anyway. Last resort is "ADSI Edit". The primary group of a user is always the Windows primary group set in Active Directory and can't be changed. If your machine is not a domain member machine or your account is a local account for some reason: Either create an /etc/passwd and/or /etc/group file with entries for your account and use that, just as before. Or enter the information into the "Comment" field of your local user entry. In the "Local Users and Groups" MMC snap-in it's called "Description". You can utilze this field even if you're running a "home edition" of Windows, using the command line. The "net user" command allows to set all values in the SAM, even if the GUI is crippled. A Cygwin SAM comment entry looks like this: <cygwin key="value" key="value" [...] /> The supported keys are home="value" Sets the Cygwin home dir to value. shell="value" Sets the Cygwin login shell to value. group="value" Sets the Cygwin primary group of the account to value, provided that the user *is* already a member of that group. This allows to override the default "None" primary group for local accounts. One nice idea here is, for instance group="Users". unix="value" Sets the NFS/Samba uid of the user to the decimal value. See the next chapter. The <cygwin .../> string can start at any point in the comment, but you have to follow the rules: - It starts with "<cygwin " and ends with "/>". - The "cygwin" string and the key names have to be lowercase. - No spaces between key and "value", just the equal sign. - The value must be placed within double quotes and it must not contain a double quote itself. The double quotes are required for the decimal values as well! CMD example: net user corinna /comment:"<cygwin home=\"/home/foo\"/>" Bash example (use single quotes): net user corinna /comment:'<cygwin home="/home/foo"/>' For changing group comments, use the `net localgroup' command. The supported key/value pair for groups are unix="value" Sets the NFS/Samba gid of the group to the decimal value. See the next chapter. =================== NFS account mapping =================== Microsoft's NFS client does not map the uid/gid values on the NFS shares to SIDs. There's no such thing as a (fake) security descriptor returned to the application. Rather, via an undocumented API an applications can fetch RFC 1813 compatible NFSv3 stat information from the share[7]. This is what Cygwin is using to show stat information for files on NFS shares. The problem is, while all other information in this stat record, like timestamps, file size etc., can be used by Cygwin, Cygwin had no way to map the values of the st_uid and st_gid members to a Windows SID for a long time. So it just faked the file owner info and claimed that it's you. However, SFU has, over time, developed multiple methods to map UNIX uid/gid values on NFS shares to Windows SIDs. You'll find the full documentation of the mapping methods in [8]. Cygwin now utilizes the RFC 2307 mapping for this purpose. This is most of the time provided by an AD domain, but it could also be a standalone LDAP mapping server. Per RFC 2307, the uid is in the attribute uidNumber. For groups, the gid is in the gidNumber attribute. When Cygwin stat's files on an NFS share, it asks the mapping server via LDAP in two different ways, depending on the role of the mapping server. - If the server is an AD domain controller, it asks for an account with uidNumber attribute == st_uid field of the stat record returned by NFS. If an account matches, AD returns the Windows SID, so we have an immediate mapping from UNIX uid to a Windows SID, if the user account has a valid uidNumber attribute. For groups, the method is the same, just that Cygwin asks for a group with gidNumber attribute == st_gid field of the stat record. - If the server is a standalone LDAP mapping server Cygwin asks for the same uidNumber/gidNumber attributes, but it can't expect that the LDAP server knows anything about Windows SIDs. Rather, the mapping server returns the account name. Cygwin then asks the DC for an account with this name, and if that succeeds, we have a mapping between UNIX uid/gid and Windows SIDs. The mapping will be cached for the lifetime of the process, and inherited by child processes. ===================== Samba account mapping ===================== A fully set up Samba with domain integration is running winbindd to map Window SIDs to artificially created UNIX uids and gids, and this mapping is transparent within the domain, so Cygwin doesn't have to do anything special. However, setting up winbindd isn't for everybody, and it fails to map Windows accounts to already existing UNIX users or groups. In contrast to NFS, Samba returns security descriptors, but unmapped UNIX accounts get special SIDs: - A UNIX user account with uid X is mapped to the Windows SID S-1-22-1-X. - A UNIX group account with gid X is mapped to SID S-1-22-2-X. As you can see, even though we have SIDs, they just reflect the actual uid/gid values on the UNIX box in the RID value. It's only marginally different from the NFS method, so why not just use the same method as for NFS? That's what Cygwin will do. If it encounters a S-1-22-x-y SID, it will perform the same RFC 2307 mapping as for NFS shares. For home users without any Windows domain or LDAP server per RFC 2307, but with a Linux machine running Samba, just add this information to your SAM account. Assuming the uid of your Linux user account is 505 and the gid of your primary group is, say, 100, just add the values to your SAM user and group accounts. The following example assumes you didn't already add something else to the comment field. To your user's SAM comment (remember: called "Description" in the GUI), add: <cygwin group="Users" unix="505"/> To the user's group SAM comment add: <cygwin unix="100"/> This should be sufficient to work on your Samba share and to see all files owned by your Linux user account as your files. =========================== The /etc/nsswitch.conf file =========================== Last, but not least, let's talk about the way to configure how the mapping works on your machine. On Linux and some other UNIXy OSes, we have a file called /etc/nsswitch.conf[9]. One part of it is to specify how the passwd and group entries are generated. That's what Cygwin now provides as well. The /etc/nsswitch.conf file is optional. If you don't have one, Cygwin uses sensible defaults. Note: The /etc/nsswitch.conf file is read exactly once by the first process of a Cygwin process tree. If there was no /etc/nsswitch.conf file when this first process started, then no other process in the running Cygwin process trees will try to read the file. If you create or change /etc/nsswitch.conf, you need to restart all Cygwin processes that need to see the change. If the process you want to see the change is a child of another process, you need to restart all of that process's parents, too. For example, if you run Vim inside the default Cygwin Terminal, Vim is a child of your shell, which is a child of mintty.exe. If you edit /etc/nsswitch.conf in that Vim instance, your shell won't immediately see the change, nor will Vim if you restart it from that same shell instance. This is because both are getting their nsswitch information from their ancestor, mintty.exe. You need to start a fresh terminal window for the change to take effect. By contrast, if you leave that Cygwin Terminal window open after making the change to /etc/nsswitch.conf, then restart a Cygwin service like cron, cron will see the change, because it is not a child of mintty.exe or any other Cygwin process. (Technically, it is a child of cygrunsrv, but that instance also restarts when you restart the service.) The reason we point all this out is that the requirements for restarting things are not quite as stringent as when you replace cygwin1.dll. If you have three process trees, you have three independent copies of the nsswitch information. If you start a fresh process tree, it will see the changes. As long as any process in an existing process tree remains running, all processes in that tree will continue to use the old information. So, what mischief can we perform with /etc/nsswitch.conf? To explain, lets have a look into an /etc/nsswitch.conf file set up to all default values: # /etc/nsswitch.conf passwd: files db group: files db db_prefix: auto db_separator: + db_enum: cache builtin The first line, starting with a hash '#' is a comment. The hash character starts a comment, just as in shell scripts. Everything up to the end of the line is ignored. So this: foo: bar # baz means, for the entry "foo", do "bar", ignore everything after the hash sign. "baz" is only a comment. The other lines define the available settings. The first word up to a colon is a keyword. Note that the colon *must* follow immediately after the keyword. This is a valid line: foo: bar This is not valid: foo : bar Apart from this restriction, the reminder of the line can have as may spaces and TABs as you like. This is a valid line: foo: bar baz Now let's have a look at the available keywords and settings. The two lines starting with the keywords "passwd" and "group" define where Cygwin gets its passwd and group information from. "files" means, fetch the information from the corresponding file in the /etc directory. "db" means, fetch the information from the Windows account databases, the SAM for local accounts, Active Directory for domain account. Examples: passwd: files Read passwd entries only from /etc/passwd. group: db Read group entries only from SAM/AD. group: files # db Read group entries only from /etc/group ("db" is ignored due to the preceding hash sign). passwd: files db Read passwd entries from /etc/passwd. If a user account isn't found, try to find it in SAM or AD. This is the default for both, passwd and group information. group: db files This is a valid entry, but the order will be ignored by Cygwin. If both, files and db are specified, Cygwin will always try the files first, then the db. The remaining entries define certain aspects of the Windows account database search. "db_prefix" determines how the Cygwin user or group name is created: db_prefix: auto This is the default. If your account is from the primary domain of your machine, or if your machine is a standalone machine (not a domain member), your Cygwin account name is just the Windows account name. If your account is from another domain, or if you're logged in as local user on a domain machine, the Cygwin username will be the combination of Windows domainname and username, with the separator char in between: MY_DOM+username (foreign domain) MACHINE+username (local account) Builtin accounts have just the separator char prepended: +LOCAL +Users Unknown accounts on NFS or Samba shares (that is, accounts which cannot be mapped to Windows user accounts via RFC 2307) get a Cygwin account name consisting of the artificial domains "Unix_User" or "Unix_Group" and the uid/gid value, for instance: Unix_User+0 (root) Unix_Group+10 (wheel) db_prefx: primary Like "auto", but primary domain accounts will be prepended by the domainname as well. db_prefix: always All accounts, even the builtin accounts, will have the domain name prepended: BUILTIN+Users As a special case, if the Cygwin account name differs from the Windows account name, it will be prepended by the artificial domain name "Posix_User" or "Posix_Group" if db_prefix is set to "always": Posix_User+cygwin_user_name Posix_Group+cygwin_group_name "db_separator" defines the spearator char used to prepend the domain name to the user or group name. The default is '+': MY_DOM+username With "db_separator", you can define any ASCII char except space, tab, carriage return, line feed, and the colon, as separator char. Example: db_separator: \ MY_DOM\username "db_enum" defines the depth of a database search, if an application calls one of the enumeration functions getpwent[10] or getgrent[11]. The problem with these functions is, they neither allow to define how many entries will be enumerated when calling them in a loop, nor do they allow to add some filter criteria. They were designed back in the days, when only /etc/passwd and /etc/group files existed and the number of user accounts on a typical UNIX system was seldomly a three-digit number. These days, with user and group databases sometimes going in the six-digit range, they are a potential burden. For that reason, Cygwin does not enumerate all user or group accounts by default, but rather just a very small list, consisting only of the accounts cached in memory by the current process, as well as a handful of predefined builtin accounts. "db_enum" allows to specify the accounts to enumerate in a fine-grained way. It takes a list of sources as argument: db_enum: source1 source2 ... The recognized sources are the following: none No output from getpwent/getgrent at all. all The opposite. Enumerates accounts from all known sources, including all trusted domains. cache Enumerate all accounts currently cached in memory. builtin Enumerate the predefined builtin accounts for backward compatibility. These are five passwd accounts (SYSTEM, LocalService, NetworkService, Administrators, TrustedInstaller) and two group accounts (SYSTEM and TrustedInstaller). files Enumerate the accounts from /etc/passwd or /etc/group. local Enumerate all accounts from the local SAM. primary Enumerate all accounts from the primary domain. alltrusted Enumerate all accounts from all trusted domains. some.domain Enumerate all accounts from the trusted domain some.domain. The trusted domain can be given as Netbios flat name (MY_DOMAIN) or as dns domain name (my_domain.corp). In contrast to the aforementioned fixed source keywords, distinct domain names are caseinsensitive. Only domains which are actually trusted domains are enumerated. Unknown domains are simply ignored. Please note that getpwent/getgrent do *not* test if an account was already listed from another source, so an account can easily show up twice or three times. Such a test would be rather tricky, nor does the Linux implementation perform such test. Here are a few examples for /etc/nsswitch.conf: db_enum: none No output from getpwent/getgrent at all. The first call to the function immediately returns a NULL pointer. db_enum: cache files Enumerate all accounts cached by the current process, plus all entries from either the /etc/passwd or /etc/group file. db_enum: cache local primary Enumerate all accounts cached by the current process, all accounts from the SAM of the local machine, and all accounts from the primary domain of the machine. db_enum: local primary alltrusted Enumerate the accounts from the machine's SAM, from the primary domain of the machine, and from all trusted domains. db_enum: primary domain1.corp sub.domain.corp domain2.net Enumerate the accounts from the primary domain and from the domains domain1.corp, sub.domain.corp and domain2.net. db_enum: all Enumerate everything and the kitchen sink. ========== Footnotes: ========== [1] http://cygwin.com/cygwin-ug-net/ntsec.html [2] This may change. Right now the file is read in 32K chunks, but we could easily read the file in 64K chunks and, if we find the file is < 64K anyway, just cache the entire bunch, like before. Not implemented yet, but something to keep in mind. [3] http://msdn.microsoft.com/en-us/library/windows/desktop/aa379166%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa379159%28v=vs.85%29.aspx [4] This is where Cygwin differs from SFU. The reason is that we need the old uid/gid values for backward compatibility. There are Cygwin packages (cron, for instance) who rely on the fact that the uid of SYSTEM is 18. In SFU, these accounts get mapped like the other built in SIDs. [5] http://support.microsoft.com/kb/243330 [6] https://tools.ietf.org/html/rfc2307 [7] https://tools.ietf.org/html/rfc1813 [8] http://msdn.microsoft.com/en-us/library/cc980032.aspx [9] http://linux.die.net/man/5/nsswitch.conf [10] http://linux.die.net/man/3/getpwent [11] http://linux.die.net/man/3/getgrent [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-06 12:52 ` Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) Corinna Vinschen 2014-05-06 12:55 ` Corinna Vinschen @ 2014-05-06 13:01 ` Corinna Vinschen 2014-05-07 12:26 ` vlado99 2014-05-06 17:01 ` Chris J. Breisch 2 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2014-05-06 13:01 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1156 bytes --] On May 6 14:52, Corinna Vinschen wrote: > - One account in the user token's group list is a special SID for a > user(!) account which apparently connects your local account with the > Microsoft Account. Here's the output from Windows' own `whoami' tool: > > MicrosoftAccount\testuser@foobar.de User S-1-11-96-3623454863-58364-18864-2661722203-1597581903-2673650909-3269597714-2381787221-1144632321-4110357092 Mandatory group, Enabled by default, Enabled group > [...] > - The maximum length of a netbios domain name is defined as DNLEN > in lmcons.h. DNLEN is 15. The new domain name "MicrosoftAccount" > has a length of 16. Cygwin uses buffers based on DNLEN :-P Btw. Does anybody here use a Microsoft Account on a non-English Windows system? If so, I'd like to see the output of /cygdrive/c/Windows/System32/whoami /groups | grep S-1-11- What I'm especially interested in is, if the domain name, "MicrosoftAccount" is localized or not. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-06 13:01 ` Corinna Vinschen @ 2014-05-07 12:26 ` vlado99 2014-05-07 12:43 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: vlado99 @ 2014-05-07 12:26 UTC (permalink / raw) To: cygwin On 6.5.2014 15:01, Corinna Vinschen wrote: > Does anybody here use a Microsoft Account on a non-English Windows system? > If so, I'd like to see the output of > > /cygdrive/c/Windows/System32/whoami /groups | grep S-1-11- > > What I'm especially interested in is, if the domain name, > "MicrosoftAccount" is localized or not. Hi, I have Windows 8.1 Pro Slovak on virtual machine. If I login using local account, output of whoami /groups doesn't contain S-1-11-. So I created Microsoft Account, logged in, and run C:\>C:\Windows\System32\whoami.exe /groups | find "S-1-11-" MicrosoftAccount\robin2014@outlook.sk User S-1-11 -96-3623454863-58364-18864-2661722203-1597581903-280192800-1280197373-3897116171 -2313688921-3621400082 Mandatory group, Enabled by default, Enabled group C:\> But "one swallow does not make summer"! In past, there was different approach to localisation to different languages. For example Czech Windows XP had localised output of command line tools, but Slovak XP had localised only GUI. Vlado -- 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] 42+ messages in thread
* Re: Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-07 12:26 ` vlado99 @ 2014-05-07 12:43 ` Corinna Vinschen 0 siblings, 0 replies; 42+ messages in thread From: Corinna Vinschen @ 2014-05-07 12:43 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1543 bytes --] On May 7 14:26, vlado99 wrote: > On 6.5.2014 15:01, Corinna Vinschen wrote: > >Does anybody here use a Microsoft Account on a non-English Windows system? > >If so, I'd like to see the output of > > > > /cygdrive/c/Windows/System32/whoami /groups | grep S-1-11- > > > >What I'm especially interested in is, if the domain name, > >"MicrosoftAccount" is localized or not. > Hi, > > I have Windows 8.1 Pro Slovak on virtual machine. If I login using > local account, output of whoami /groups doesn't contain S-1-11-. So > I created Microsoft Account, logged in, and run > > C:\>C:\Windows\System32\whoami.exe /groups | find "S-1-11-" > MicrosoftAccount\robin2014@outlook.sk User S-1-11 > -96-3623454863-58364-18864-2661722203-1597581903-280192800-1280197373-3897116171 > -2313688921-3621400082 Mandatory group, Enabled by default, Enabled group > > C:\> > > But "one swallow does not make summer"! In past, there was different > approach to localisation to different languages. For example Czech > Windows XP had localised output of command line tools, but Slovak XP > had localised only GUI. Yeah, I agree. So far we only know that the Slovakian and the German (tested off-list) versions use non-localized versions of this fake domain. But nevertheless, thanks for going out of your way testing this. Much appreciated. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-06 12:52 ` Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) Corinna Vinschen 2014-05-06 12:55 ` Corinna Vinschen 2014-05-06 13:01 ` Corinna Vinschen @ 2014-05-06 17:01 ` Chris J. Breisch 2014-05-06 17:16 ` Corinna Vinschen 2 siblings, 1 reply; 42+ messages in thread From: Chris J. Breisch @ 2014-05-06 17:01 UTC (permalink / raw) To: cygwin Corinna Vinschen wrote: > But, here's the deal. I eventually gave up and created a Microsoft > Account on my W8.1 machine. And this was definitely the right thing to > do, for a couple of reasons: > > - For a start, it uncovered a case-sensitivity bug in my new SAM/AD > account code. > > - In my case `id' showed clearly that in my user token the primary > group is set to my user account itself. I'm using my new SAM/AD > code, so I can see what happens if there are no /etc/passwd and > /etc/group files in the way. > > - This explains why your user account shows up in /etc/group. `mkpasswd > -c' creates the group info from your user token, and the primary group > in your user token is your own user account. > > - The reason that you *seem* to have "None" as primary group is a result > of historical laziness: mkpasswd simply sets the primary gid to 513 > for all local accounts, since that's what it always was so far. > > - The reason that setting your primary group to "None" doesn't really > work (and thus, neither do file group permissions) is the fact that > the "None" group is no longer in the user token's group list. For > kicks, if you call `net user<yourusername>' it still prints > > Global Group memberships *None > > - The reason that setting your primary group to "Users" works fine > is the fact that it *is* in the user token's group list. > > - One account in the user token's group list is a special SID for a > user(!) account which apparently connects your local account with the > Microsoft Account. Here's the output from Windows' own `whoami' tool: > > MicrosoftAccount\testuser@foobar.de User S-1-11-96-3623454863-58364-18864-2661722203-1597581903-2673650909-3269597714-2381787221-1144632321-4110357092 Mandatory group, Enabled by default, Enabled group > > The problem here is the length of the SID. So far the Cygwin code > assumes that a SID has a maximum number of 8 subauthorities. This is > based on the fact that the Win32 routine to generate a SID allows a > maximum of 8 subauthorities, so it was a relatively safe assumption. > Not so, anymore. The subauthorities are the numbers starting at the > 96. If I count correctly we now have a SID with 11 subauthorities. > > This is, of course, my fault. In reality there's a macro in the > Windows headers called SID_MAX_SUB_AUTHORITIES, which is set to 15. > But so far there were never more than 6 subauthorities, so I never > had a reason to look :| > > As a sidenote, the SIDs of the Microsoft Accounts are undocumented > and no matching values exist even in the latest Microsoft VC++ header > files... > > - The maximum length of a netbios domain name is defined as DNLEN > in lmcons.h. DNLEN is 15. The new domain name "MicrosoftAccount" > has a length of 16. Cygwin uses buffers based on DNLEN :-P > > That's the state for now. I patched Cygwin to be able to handle all of > the above, but I didn't touch the primary group in the user token yet. > > So, if you download the today's developer snapshot from > http://cygwin.com/snapshots/, you get at least a somewhat sane > behaviour: > > - If you have no passwd/group files (or set /etc/nsswitch.conf to > > passwd: db > group: db > > so that you just rely on the new SAM/AD code in Cygwin, you get a > primary group == your user account. The output of `id' reflects > what I wrote above. You will see a group called > MicrosoftAccount\<your email address> as part of the supplementary > group list. Hmmm. Yes, I see that. It seems that the "None" weirdness has just transferred itself to this other group though. Now my test file is owned by Chris.Chris instead of Chris.None and the group permissions still mirror the owner permissions. I dropped my /etc/passwd and am using the new stuff. > > - If you still use your current /etc/passwd, you will still have the > "None" weirdness perhaps, because the group with gid 513 is simply > not in your user token, and there's nothing Cygwin can do about that. > > - If you want to utilize Cygwin's capability to override your > primary group, you have two choices: > > - Download the complete cygwin-inst-20140506.tar.xz for your platform > (x86/x86_64) and use the new mkpasswd and mkgroup tools in there > to generate new /etc/passwd and /etc/group files. Then override > your primary group with the value 545, just like before. > > - Alternatively, change the primary group in the Windows SAM, as > described in the document attached to this mail. It's the latest > version of the preliminary documentation of the new account handling > in Cygwin. See the chapter "Cygwin user names, home dirs, login > shells". > > Other than that, I'm open to discuss the necessity(?) to override > the primary group by default. But, in fact, I'm not sure this really > makes sense. Linux systems default to creating a user-specific group > account and using that as the user's primary group for years. The > Windows Account technique isn't quite as nice, but admittedly, it > does its job just as well. Yes, I've experienced that on Linux, but I don't recall having these file permission issues there. Perhaps I just never noticed though. > > Thanks, > Corinna > Thanks for looking into all of this. -- Chris J. Breisch -- 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] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-06 17:01 ` Chris J. Breisch @ 2014-05-06 17:16 ` Corinna Vinschen 2014-05-06 18:22 ` Chris J. Breisch 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2014-05-06 17:16 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1814 bytes --] On May 6 13:01, Chris J. Breisch wrote: > Corinna Vinschen wrote: > >Other than that, I'm open to discuss the necessity(?) to override > >the primary group by default. But, in fact, I'm not sure this really > >makes sense. Linux systems default to creating a user-specific group > >account and using that as the user's primary group for years. The > >Windows Account technique isn't quite as nice, but admittedly, it > >does its job just as well. > > Yes, I've experienced that on Linux, but I don't recall having these > file permission issues there. Perhaps I just never noticed though. No, it *is* different, On Linux you get a user account called "Chris" and a group account called "Chris", and they are different because users and groups are totally different beasts on POSIX systems. You can have a user with uid 42 and a group with gid 42 and they are still different. On Windows, users and groups are identified not by uid/gid, but by their SID. The SID is a unique value, but other than that, a SID can be a user or a group and in lots of cases Windows doesn't care. A group can be owner of a file and a user can be the group of the file, it just doesn't matter to Windows. The permission "problem" you're seeing is a result of that. Your user *and* your primary group are both your user's SID. Therefore the same account is user and primary group at the same time. Therefore, if the file is created, it gets created with an ACL with user and group being the same account. Therefore the POSIX translation of the user and group permissions on the file are always the same. Does this clear it up? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-06 17:16 ` Corinna Vinschen @ 2014-05-06 18:22 ` Chris J. Breisch 2014-05-07 11:57 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Chris J. Breisch @ 2014-05-06 18:22 UTC (permalink / raw) To: cygwin Corinna Vinschen wrote: > On May 6 13:01, Chris J. Breisch wrote: >> Corinna Vinschen wrote: >>> Other than that, I'm open to discuss the necessity(?) to override >>> the primary group by default. But, in fact, I'm not sure this really >>> makes sense. Linux systems default to creating a user-specific group >>> account and using that as the user's primary group for years. The >>> Windows Account technique isn't quite as nice, but admittedly, it >>> does its job just as well. >> Yes, I've experienced that on Linux, but I don't recall having these >> file permission issues there. Perhaps I just never noticed though. > > No, it *is* different, On Linux you get a user account called "Chris" > and a group account called "Chris", and they are different because users > and groups are totally different beasts on POSIX systems. You can have > a user with uid 42 and a group with gid 42 and they are still different. > > On Windows, users and groups are identified not by uid/gid, but by > their SID. The SID is a unique value, but other than that, a SID can > be a user or a group and in lots of cases Windows doesn't care. > A group can be owner of a file and a user can be the group of the file, > it just doesn't matter to Windows. > > The permission "problem" you're seeing is a result of that. Your user > *and* your primary group are both your user's SID. Therefore the same > account is user and primary group at the same time. Therefore, if > the file is created, it gets created with an ACL with user and group > being the same account. Therefore the POSIX translation of the user > and group permissions on the file are always the same. > > Does this clear it up? Yes, that makes complete sense. Thank you again. -- Chris J. Breisch -- 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] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-06 18:22 ` Chris J. Breisch @ 2014-05-07 11:57 ` Corinna Vinschen 2014-05-07 12:40 ` Corinna Vinschen ` (2 more replies) 0 siblings, 3 replies; 42+ messages in thread From: Corinna Vinschen @ 2014-05-07 11:57 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2975 bytes --] On May 6 14:22, Chris J. Breisch wrote: > Corinna Vinschen wrote: > >On May 6 13:01, Chris J. Breisch wrote: > >>Corinna Vinschen wrote: > >>>Other than that, I'm open to discuss the necessity(?) to override > >>>the primary group by default. But, in fact, I'm not sure this really > >>>makes sense. Linux systems default to creating a user-specific group > >>>account and using that as the user's primary group for years. The > >>>Windows Account technique isn't quite as nice, but admittedly, it > >>>does its job just as well. > >>Yes, I've experienced that on Linux, but I don't recall having these > >>file permission issues there. Perhaps I just never noticed though. > > > >No, it *is* different, On Linux you get a user account called "Chris" > >and a group account called "Chris", and they are different because users > >and groups are totally different beasts on POSIX systems. You can have > >a user with uid 42 and a group with gid 42 and they are still different. > > > >On Windows, users and groups are identified not by uid/gid, but by > >their SID. The SID is a unique value, but other than that, a SID can > >be a user or a group and in lots of cases Windows doesn't care. > >A group can be owner of a file and a user can be the group of the file, > >it just doesn't matter to Windows. > > > >The permission "problem" you're seeing is a result of that. Your user > >*and* your primary group are both your user's SID. Therefore the same > >account is user and primary group at the same time. Therefore, if > >the file is created, it gets created with an ACL with user and group > >being the same account. Therefore the POSIX translation of the user > >and group permissions on the file are always the same. > > > >Does this clear it up? > > Yes, that makes complete sense. Thank you again. I toyed around with the Microsoft Account a bit more. And here's why the primary group SID being identical to the user SID is not a good idea: Security checks. For instance: $ echo $USER VMBERT8164+local_000 $ screen Directory /tmp/uscreens/S-VMBERT8164+local_000 must have mode 700. Huh? $ ls -l /tmp/uscreens/ total 0 drwxrwx---+ 1 VMBERT8164+local_000 VMBERT8164+local_000 0 May 7 12:44 S-VMBERT8164+local_000 Uh Oh. This will be a problem with other security sensitive applications, too. Sshd comes to mind. So I guess we really should make sure the primary group SID is some valid group, not the user's SID. "None" is not an option since it's not in the user token group list. "Users" seems to be the best choice at first sight. Alternatively we could use the S-1-11-xxx SID of the Microsoft Account. That would be in line with the idea to have a user-specific primary group. Thoughts? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-07 11:57 ` Corinna Vinschen @ 2014-05-07 12:40 ` Corinna Vinschen 2014-05-07 14:09 ` Chris J. Breisch 2014-05-07 14:05 ` Andrey Repin 2014-05-07 14:05 ` Chris J. Breisch 2 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2014-05-07 12:40 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2084 bytes --] On May 7 13:57, Corinna Vinschen wrote: > I toyed around with the Microsoft Account a bit more. And here's why > the primary group SID being identical to the user SID is not a good > idea: > > Security checks. > > For instance: > > $ echo $USER > VMBERT8164+local_000 > $ screen > Directory /tmp/uscreens/S-VMBERT8164+local_000 must have mode 700. > > Huh? > > $ ls -l /tmp/uscreens/ > total 0 > drwxrwx---+ 1 VMBERT8164+local_000 VMBERT8164+local_000 0 May 7 12:44 S-VMBERT8164+local_000 > > Uh Oh. > > This will be a problem with other security sensitive applications, too. > Sshd comes to mind. > > So I guess we really should make sure the primary group SID is some > valid group, not the user's SID. > > "None" is not an option since it's not in the user token group list. > > "Users" seems to be the best choice at first sight. > > Alternatively we could use the S-1-11-xxx SID of the Microsoft Account. > That would be in line with the idea to have a user-specific primary > group. > > Thoughts? And here's a problem which I'm not sure how to solve at all: When calling the latest mkpasswd, the primary group of the local user account backing the Microsoft Account will *still* be "None". The reason is that the local account is just the same old account as usual. Its default primary group *is* "None". Only when logging in via the Micosoft Account email address, the user token will not reflect what's stored in the local SAM, but will have been changed by the OS as outlined in this thread. So, when a user decides to create a passwd file rather than using the SAM/DB code in Cygwin, the information generated by mkpasswd will not match the user token, and the primary group stored in /etc/passwd will not even be available at all in the user token. I have not the faintest idea how to workaround this schizophrenia. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-07 12:40 ` Corinna Vinschen @ 2014-05-07 14:09 ` Chris J. Breisch 2014-05-07 14:46 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Chris J. Breisch @ 2014-05-07 14:09 UTC (permalink / raw) To: cygwin Corinna Vinschen wrote: > On May 7 13:57, Corinna Vinschen wrote: >> I toyed around with the Microsoft Account a bit more. And here's why >> the primary group SID being identical to the user SID is not a good >> idea: >> >> Security checks. >> >> For instance: >> >> $ echo $USER >> VMBERT8164+local_000 >> $ screen >> Directory /tmp/uscreens/S-VMBERT8164+local_000 must have mode 700. >> >> Huh? >> >> $ ls -l /tmp/uscreens/ >> total 0 >> drwxrwx---+ 1 VMBERT8164+local_000 VMBERT8164+local_000 0 May 7 12:44 S-VMBERT8164+local_000 >> >> Uh Oh. >> >> This will be a problem with other security sensitive applications, too. >> Sshd comes to mind. >> >> So I guess we really should make sure the primary group SID is some >> valid group, not the user's SID. >> >> "None" is not an option since it's not in the user token group list. >> >> "Users" seems to be the best choice at first sight. >> >> Alternatively we could use the S-1-11-xxx SID of the Microsoft Account. >> That would be in line with the idea to have a user-specific primary >> group. >> >> Thoughts? > > And here's a problem which I'm not sure how to solve at all: > > When calling the latest mkpasswd, the primary group of the local > user account backing the Microsoft Account will *still* be "None". > > The reason is that the local account is just the same old account > as usual. Its default primary group *is* "None". > > Only when logging in via the Micosoft Account email address, the > user token will not reflect what's stored in the local SAM, but > will have been changed by the OS as outlined in this thread. > > So, when a user decides to create a passwd file rather than using > the SAM/DB code in Cygwin, the information generated by mkpasswd > will not match the user token, and the primary group stored in > /etc/passwd will not even be available at all in the user token. > > I have not the faintest idea how to workaround this schizophrenia. > > > Corinna > Oh wow. It took me two reads of this to understand it. Caffeine is finally kicking in, I guess. Unless you just want to hard code the primary group that mkpasswd generates to "Users" for any account that it would tend to want to set as "None". That would be some smelly code though. -- Chris J. Breisch -- 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] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-07 14:09 ` Chris J. Breisch @ 2014-05-07 14:46 ` Corinna Vinschen 2014-05-08 20:09 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2014-05-07 14:46 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1780 bytes --] On May 7 10:09, Chris J. Breisch wrote: > Corinna Vinschen wrote: > >And here's a problem which I'm not sure how to solve at all: > > > >When calling the latest mkpasswd, the primary group of the local > >user account backing the Microsoft Account will *still* be "None". > > > >The reason is that the local account is just the same old account > >as usual. Its default primary group *is* "None". > > > >Only when logging in via the Micosoft Account email address, the > >user token will not reflect what's stored in the local SAM, but > >will have been changed by the OS as outlined in this thread. > > > >So, when a user decides to create a passwd file rather than using > >the SAM/DB code in Cygwin, the information generated by mkpasswd > >will not match the user token, and the primary group stored in > >/etc/passwd will not even be available at all in the user token. > > > >I have not the faintest idea how to workaround this schizophrenia. > > > > > >Corinna > > > Oh wow. It took me two reads of this to understand it. Caffeine is > finally kicking in, I guess. Unless you just want to hard code the > primary group that mkpasswd generates to "Users" for any account > that it would tend to want to set as "None". That would be some > smelly code though. Hmm, but it might fix a couple of problems. If we go ahead and always convert the "None" primary group to "Users", we'd have a pretty stable state, which works nicely for local accounts, independently of habving logged in as normal account or as Microsoft Account. This might be the easiest workaound, in fact. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-07 14:46 ` Corinna Vinschen @ 2014-05-08 20:09 ` Corinna Vinschen 2014-05-08 23:18 ` Robert Pendell 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2014-05-08 20:09 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2445 bytes --] On May 7 16:46, Corinna Vinschen wrote: > On May 7 10:09, Chris J. Breisch wrote: > > Corinna Vinschen wrote: > > >And here's a problem which I'm not sure how to solve at all: > > > > > >When calling the latest mkpasswd, the primary group of the local > > >user account backing the Microsoft Account will *still* be "None". > > > > > >The reason is that the local account is just the same old account > > >as usual. Its default primary group *is* "None". > > > > > >Only when logging in via the Micosoft Account email address, the > > >user token will not reflect what's stored in the local SAM, but > > >will have been changed by the OS as outlined in this thread. > > > > > >So, when a user decides to create a passwd file rather than using > > >the SAM/DB code in Cygwin, the information generated by mkpasswd > > >will not match the user token, and the primary group stored in > > >/etc/passwd will not even be available at all in the user token. > > > > > >I have not the faintest idea how to workaround this schizophrenia. > > > > > > > > >Corinna > > > > > Oh wow. It took me two reads of this to understand it. Caffeine is > > finally kicking in, I guess. Unless you just want to hard code the > > primary group that mkpasswd generates to "Users" for any account > > that it would tend to want to set as "None". That would be some > > smelly code though. > > Hmm, but it might fix a couple of problems. If we go ahead and > always convert the "None" primary group to "Users", we'd have a > pretty stable state, which works nicely for local accounts, > independently of habving logged in as normal account or as Microsoft > Account. This might be the easiest workaound, in fact. I created a new snapshot on http://cygwin.com/snapshots/ which introduces the following behaviour, which is a bit less intrusive: If a local account is connected to a Microsoft Account, the primary group defaults to "Users". If it's a normal local accout it defaults to "None", as usual. This also covers mkpasswd from the snapshot. This does not work if you continue to use an already existing /etc/passwd file. I have no good solution for this sccenario, other than a (yet to be written) FAQ entry. Hope that helps nevertheless. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-08 20:09 ` Corinna Vinschen @ 2014-05-08 23:18 ` Robert Pendell 2014-05-09 0:12 ` Ken Brown 2014-05-09 7:42 ` Corinna Vinschen 0 siblings, 2 replies; 42+ messages in thread From: Robert Pendell @ 2014-05-08 23:18 UTC (permalink / raw) To: cygwin On Thu, May 8, 2014 at 4:09 PM, Corinna Vinschen wrote: > On May 7 16:46, Corinna Vinschen wrote: >> On May 7 10:09, Chris J. Breisch wrote: >> > Corinna Vinschen wrote: >> > >And here's a problem which I'm not sure how to solve at all: >> > > >> > >When calling the latest mkpasswd, the primary group of the local >> > >user account backing the Microsoft Account will *still* be "None". >> > > >> > >The reason is that the local account is just the same old account >> > >as usual. Its default primary group *is* "None". >> > > >> > >Only when logging in via the Micosoft Account email address, the >> > >user token will not reflect what's stored in the local SAM, but >> > >will have been changed by the OS as outlined in this thread. >> > > >> > >So, when a user decides to create a passwd file rather than using >> > >the SAM/DB code in Cygwin, the information generated by mkpasswd >> > >will not match the user token, and the primary group stored in >> > >/etc/passwd will not even be available at all in the user token. >> > > >> > >I have not the faintest idea how to workaround this schizophrenia. >> > > >> > > >> > >Corinna >> > > >> > Oh wow. It took me two reads of this to understand it. Caffeine is >> > finally kicking in, I guess. Unless you just want to hard code the >> > primary group that mkpasswd generates to "Users" for any account >> > that it would tend to want to set as "None". That would be some >> > smelly code though. >> >> Hmm, but it might fix a couple of problems. If we go ahead and >> always convert the "None" primary group to "Users", we'd have a >> pretty stable state, which works nicely for local accounts, >> independently of habving logged in as normal account or as Microsoft >> Account. This might be the easiest workaound, in fact. > > I created a new snapshot on http://cygwin.com/snapshots/ which > introduces the following behaviour, which is a bit less intrusive: > > If a local account is connected to a Microsoft Account, the primary > group defaults to "Users". If it's a normal local accout it defaults > to "None", as usual. This also covers mkpasswd from the snapshot. > > This does not work if you continue to use an already existing > /etc/passwd file. I have no good solution for this sccenario, other > than a (yet to be written) FAQ entry. > > Hope that helps nevertheless. > > > Corinna > Thanks for all the effort you have put forth on this issue Corinna. I checked the snapshot today and found the behavior to be matching what you described. An expected side effect right now is that old files still have the group SID set to the user SID as well as all the other installed files placed by the OS however there isn't much we can do there beyond changing the group manually for the files. On that note I used the larger inst package (to get updates to mkpasswd and the like) and noticed that there is a /usr/lib and /usr/bin folder with the updated files however cygwin mounts /lib and /bin on top of the respective folders making any files installed there inaccessible in a normal cygwin run. Is this intended? For now I manually moved those folders to the root therefore overwriting old files with the newer ones. -- 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] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-08 23:18 ` Robert Pendell @ 2014-05-09 0:12 ` Ken Brown 2014-05-09 1:34 ` Robert Pendell 2014-05-09 6:11 ` Achim Gratz 2014-05-09 7:42 ` Corinna Vinschen 1 sibling, 2 replies; 42+ messages in thread From: Ken Brown @ 2014-05-09 0:12 UTC (permalink / raw) To: cygwin On 5/8/2014 7:17 PM, Robert Pendell wrote: > On Thu, May 8, 2014 at 4:09 PM, Corinna Vinschen wrote: >> On May 7 16:46, Corinna Vinschen wrote: >>> On May 7 10:09, Chris J. Breisch wrote: >>>> Corinna Vinschen wrote: >>>>> And here's a problem which I'm not sure how to solve at all: >>>>> >>>>> When calling the latest mkpasswd, the primary group of the local >>>>> user account backing the Microsoft Account will *still* be "None". >>>>> >>>>> The reason is that the local account is just the same old account >>>>> as usual. Its default primary group *is* "None". >>>>> >>>>> Only when logging in via the Micosoft Account email address, the >>>>> user token will not reflect what's stored in the local SAM, but >>>>> will have been changed by the OS as outlined in this thread. >>>>> >>>>> So, when a user decides to create a passwd file rather than using >>>>> the SAM/DB code in Cygwin, the information generated by mkpasswd >>>>> will not match the user token, and the primary group stored in >>>>> /etc/passwd will not even be available at all in the user token. >>>>> >>>>> I have not the faintest idea how to workaround this schizophrenia. >>>>> >>>>> >>>>> Corinna >>>>> >>>> Oh wow. It took me two reads of this to understand it. Caffeine is >>>> finally kicking in, I guess. Unless you just want to hard code the >>>> primary group that mkpasswd generates to "Users" for any account >>>> that it would tend to want to set as "None". That would be some >>>> smelly code though. >>> >>> Hmm, but it might fix a couple of problems. If we go ahead and >>> always convert the "None" primary group to "Users", we'd have a >>> pretty stable state, which works nicely for local accounts, >>> independently of habving logged in as normal account or as Microsoft >>> Account. This might be the easiest workaound, in fact. >> >> I created a new snapshot on http://cygwin.com/snapshots/ which >> introduces the following behaviour, which is a bit less intrusive: >> >> If a local account is connected to a Microsoft Account, the primary >> group defaults to "Users". If it's a normal local accout it defaults >> to "None", as usual. This also covers mkpasswd from the snapshot. >> >> This does not work if you continue to use an already existing >> /etc/passwd file. I have no good solution for this sccenario, other >> than a (yet to be written) FAQ entry. >> >> Hope that helps nevertheless. >> >> >> Corinna >> > > Thanks for all the effort you have put forth on this issue Corinna. I > checked the snapshot today and found the behavior to be matching what > you described. An expected side effect right now is that old files > still have the group SID set to the user SID as well as all the other > installed files placed by the OS however there isn't much we can do > there beyond changing the group manually for the files. > > On that note I used the larger inst package (to get updates to > mkpasswd and the like) and noticed that there is a /usr/lib and > /usr/bin folder with the updated files however cygwin mounts /lib and > /bin on top of the respective folders making any files installed there > inaccessible in a normal cygwin run. This doesn't happen if you install the snapshot by the method suggested in the FAQ: http://cygwin.com/faq.html#faq.setup.snapshots Ken -- 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] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-09 0:12 ` Ken Brown @ 2014-05-09 1:34 ` Robert Pendell 2014-05-09 6:11 ` Achim Gratz 1 sibling, 0 replies; 42+ messages in thread From: Robert Pendell @ 2014-05-09 1:34 UTC (permalink / raw) To: cygwin On Thu, May 8, 2014 at 8:12 PM, Ken Brown <kbrown@cornell.edu> wrote: > On 5/8/2014 7:17 PM, Robert Pendell wrote: >> >> On Thu, May 8, 2014 at 4:09 PM, Corinna Vinschen wrote: >>> >>> On May 7 16:46, Corinna Vinschen wrote: >>>> >>>> On May 7 10:09, Chris J. Breisch wrote: >>>>> >>>>> Corinna Vinschen wrote: >>>>>> >>>>>> And here's a problem which I'm not sure how to solve at all: >>>>>> >>>>>> When calling the latest mkpasswd, the primary group of the local >>>>>> user account backing the Microsoft Account will *still* be "None". >>>>>> >>>>>> The reason is that the local account is just the same old account >>>>>> as usual. Its default primary group *is* "None". >>>>>> >>>>>> Only when logging in via the Micosoft Account email address, the >>>>>> user token will not reflect what's stored in the local SAM, but >>>>>> will have been changed by the OS as outlined in this thread. >>>>>> >>>>>> So, when a user decides to create a passwd file rather than using >>>>>> the SAM/DB code in Cygwin, the information generated by mkpasswd >>>>>> will not match the user token, and the primary group stored in >>>>>> /etc/passwd will not even be available at all in the user token. >>>>>> >>>>>> I have not the faintest idea how to workaround this schizophrenia. >>>>>> >>>>>> >>>>>> Corinna >>>>>> >>>>> Oh wow. It took me two reads of this to understand it. Caffeine is >>>>> finally kicking in, I guess. Unless you just want to hard code the >>>>> primary group that mkpasswd generates to "Users" for any account >>>>> that it would tend to want to set as "None". That would be some >>>>> smelly code though. >>>> >>>> >>>> Hmm, but it might fix a couple of problems. If we go ahead and >>>> always convert the "None" primary group to "Users", we'd have a >>>> pretty stable state, which works nicely for local accounts, >>>> independently of habving logged in as normal account or as Microsoft >>>> Account. This might be the easiest workaound, in fact. >>> >>> >>> I created a new snapshot on http://cygwin.com/snapshots/ which >>> introduces the following behaviour, which is a bit less intrusive: >>> >>> If a local account is connected to a Microsoft Account, the primary >>> group defaults to "Users". If it's a normal local accout it defaults >>> to "None", as usual. This also covers mkpasswd from the snapshot. >>> >>> This does not work if you continue to use an already existing >>> /etc/passwd file. I have no good solution for this sccenario, other >>> than a (yet to be written) FAQ entry. >>> >>> Hope that helps nevertheless. >>> >>> >>> Corinna >>> >> >> Thanks for all the effort you have put forth on this issue Corinna. I >> checked the snapshot today and found the behavior to be matching what >> you described. An expected side effect right now is that old files >> still have the group SID set to the user SID as well as all the other >> installed files placed by the OS however there isn't much we can do >> there beyond changing the group manually for the files. >> >> On that note I used the larger inst package (to get updates to >> mkpasswd and the like) and noticed that there is a /usr/lib and >> /usr/bin folder with the updated files however cygwin mounts /lib and >> /bin on top of the respective folders making any files installed there >> inaccessible in a normal cygwin run. > > > This doesn't happen if you install the snapshot by the method suggested in > the FAQ: > > http://cygwin.com/faq.html#faq.setup.snapshots > > Ken > Point well taken there. *Wonders why he didn't think of that* -- 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] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-09 0:12 ` Ken Brown 2014-05-09 1:34 ` Robert Pendell @ 2014-05-09 6:11 ` Achim Gratz 1 sibling, 0 replies; 42+ messages in thread From: Achim Gratz @ 2014-05-09 6:11 UTC (permalink / raw) To: cygwin Ken Brown <kbrown <at> cornell.edu> writes: > This doesn't happen if you install the snapshot by the method suggested > in the FAQ: > > http://cygwin.com/faq.html#faq.setup.snapshots > Or just make a package out of the snapshot and then install it via setup: --8<---------------cut here---------------start------------->8--- .PHONY: all install clean force-clean clean-install snapshot install-snapshot snapshot-debuginfo install-snapshot-debuginfo CV ?= 1.7.29 CR ?= 2 CVR = $(CV)-$(CR) SD ?= 20140508 ARCH ?= $(subst i686,x86,$(shell arch)) CYGMIR = /mnt/mirror/cygwin/$(ARCH)/release/cygwin CYGDEB = $(CYGMIR)/cygwin-debuginfo SNAPSHOT = $(PWD)/$(ARCH)/snapshot-$(SD) SNAPDEB = $(PWD)/$(ARCH)/snapshot-debuginfo-$(SD) SNAPURL = http://cygwin.com/snapshots/$(ARCH) PATCH = /mnt/mirror/patch/$(ARCH)/release/cygwin PATCHDEB = $(PATCH)/cygwin-debuginfo all: snapshot snapshot-debuginfo install: clean-install clean install-snapshot install-snapshot-debuginfo force-clean clean force-clean: rm -fr $(SNAPSHOT) $(SNAPDEB) *.bz2 *.xz *.dbg clean-install: clean rm -f $(PATCH)/cygwin-$(CVR)s$(SD).tar.* $(PATCHDEB)/cygwin-debuginfo-$(CVR)s$(SD).tar.* cygwin-inst-$(SD).tar.xz cygwin1-$(SD).dbg.xz: wget $(SNAPURL)/$@ snapshot: cygwin-inst-$(SD).tar.xz mkdir -p $(SNAPSHOT) $(PATCH) cp -p $(CYGMIR)/setup.hint $(PATCH) tar -C $(SNAPSHOT) -xf $(CYGMIR)/cygwin-$(CVR).tar.xz tar -C $(SNAPSHOT) -xf cygwin-inst-$(SD).tar.xz install-snapshot: snapshot mkdir -p $(PATCH) tar -C $(SNAPSHOT) -Jcf $(PATCH)/cygwin-$(CVR)s$(SD).tar.xz etc/ usr/ snapshot-debuginfo: cygwin1-$(SD).dbg.xz mkdir -p $(SNAPDEB) $(PATCHDEB) cp -p $(CYGDEB)/setup.hint $(PATCHDEB) tar -C $(SNAPDEB) -xf $(CYGDEB)/cygwin-debuginfo-$(CVR).tar.xz unxz -c cygwin1-$(SD).dbg.xz > $(SNAPDEB)/usr/lib/debug/usr/bin/cygwin1.dbg touch -r cygwin1-$(SD).dbg.xz $(SNAPDEB)/usr/lib/debug/usr/bin/cygwin1.dbg install-snapshot-debuginfo: snapshot-debuginfo mkdir -p $(PATCHDEB) tar -C $(SNAPDEB) -Jcf $(PATCHDEB)/cygwin-debuginfo-$(CVR)s$(SD).tar.xz usr/ --8<---------------cut here---------------end--------------->8--- Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-08 23:18 ` Robert Pendell 2014-05-09 0:12 ` Ken Brown @ 2014-05-09 7:42 ` Corinna Vinschen 1 sibling, 0 replies; 42+ messages in thread From: Corinna Vinschen @ 2014-05-09 7:42 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1482 bytes --] On May 8 19:17, Robert Pendell wrote: > On Thu, May 8, 2014 at 4:09 PM, Corinna Vinschen wrote: > > I created a new snapshot on http://cygwin.com/snapshots/ which > > introduces the following behaviour, which is a bit less intrusive: > > > > If a local account is connected to a Microsoft Account, the primary > > group defaults to "Users". If it's a normal local accout it defaults > > to "None", as usual. This also covers mkpasswd from the snapshot. > > > > This does not work if you continue to use an already existing > > /etc/passwd file. I have no good solution for this sccenario, other > > than a (yet to be written) FAQ entry. > > > > Hope that helps nevertheless. > > Thanks for all the effort you have put forth on this issue Corinna. I > checked the snapshot today and found the behavior to be matching what > you described. An expected side effect right now is that old files > still have the group SID set to the user SID as well as all the other > installed files placed by the OS however there isn't much we can do > there beyond changing the group manually for the files. Indeed. Cygwin can't (and must not) change the permissions of existing files. But usually this shoudn't hurt, unless a file of a security sensitive application is affected. Thanks for testing! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-07 11:57 ` Corinna Vinschen 2014-05-07 12:40 ` Corinna Vinschen @ 2014-05-07 14:05 ` Andrey Repin 2014-05-07 14:20 ` Corinna Vinschen 2014-05-07 14:05 ` Chris J. Breisch 2 siblings, 1 reply; 42+ messages in thread From: Andrey Repin @ 2014-05-07 14:05 UTC (permalink / raw) To: Corinna Vinschen Greetings, Corinna Vinschen! > I toyed around with the Microsoft Account a bit more. And here's why > the primary group SID being identical to the user SID is not a good > idea: > Security checks. > For instance: > $ echo $USER > VMBERT8164+local_000 > $ screen > Directory /tmp/uscreens/S-VMBERT8164+local_000 must have mode 700. > Huh? > $ ls -l /tmp/uscreens/ > total 0 > drwxrwx---+ 1 VMBERT8164+local_000 VMBERT8164+local_000 0 May 7 12:44 S-VMBERT8164+local_000 > Uh Oh. I concur. But mostly because of blind check "if it's not 700, it's wrong". No, it's not wrong, you dumb piece of code, it's your check isn't right. > This will be a problem with other security sensitive applications, too. > Sshd comes to mind. > So I guess we really should make sure the primary group SID is some > valid group, not the user's SID. > "None" is not an option since it's not in the user token group list. > "Users" seems to be the best choice at first sight. For local SAM account. > Alternatively we could use the S-1-11-xxx SID of the Microsoft Account. > That would be in line with the idea to have a user-specific primary > group. For M$ accounts, perhaps. > Thoughts? I'm with you on this one. P.S. When you said I can set up a primary group for my account in SAM database, what did you mean? The <cygwin/> magic or something more system-specific? -- WBR, Andrey Repin (anrdaemon@yandex.ru) 07.05.2014, <17:49> 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] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-07 14:05 ` Andrey Repin @ 2014-05-07 14:20 ` Corinna Vinschen 2014-05-07 14:43 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2014-05-07 14:20 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2059 bytes --] On May 7 17:53, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > > I toyed around with the Microsoft Account a bit more. And here's why > > the primary group SID being identical to the user SID is not a good > > idea: > > > Security checks. > > > For instance: > > > $ echo $USER > > VMBERT8164+local_000 > > $ screen > > Directory /tmp/uscreens/S-VMBERT8164+local_000 must have mode 700. > > > Huh? > > > $ ls -l /tmp/uscreens/ > > total 0 > > drwxrwx---+ 1 VMBERT8164+local_000 VMBERT8164+local_000 0 May 7 12:44 S-VMBERT8164+local_000 > > > Uh Oh. > > I concur. > But mostly because of blind check "if it's not 700, it's wrong". > No, it's not wrong, you dumb piece of code, it's your check isn't right. No, the check is right from a POSIX POV. How is a POSIX application supposed to know that the group with gid 12345 is in fact the user with the uid 12345? That's not possible in a POSIX environment. > > This will be a problem with other security sensitive applications, too. > > Sshd comes to mind. > > > So I guess we really should make sure the primary group SID is some > > valid group, not the user's SID. > > > "None" is not an option since it's not in the user token group list. > > > "Users" seems to be the best choice at first sight. > > For local SAM account. ...or "Domain Users" for AD accounts, probably. > > Alternatively we could use the S-1-11-xxx SID of the Microsoft Account. > > That would be in line with the idea to have a user-specific primary > > group. > > For M$ accounts, perhaps. Eh? This thread *is* about Microsoft Accounts. We don't have this problem for normal accounts. > When you said I can set up a primary group for my account in SAM database, > what did you mean? The <cygwin/> magic or something more system-specific? The <cygwin/> magic, yes. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-07 14:20 ` Corinna Vinschen @ 2014-05-07 14:43 ` Corinna Vinschen 0 siblings, 0 replies; 42+ messages in thread From: Corinna Vinschen @ 2014-05-07 14:43 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1922 bytes --] On May 7 16:20, Corinna Vinschen wrote: > On May 7 17:53, Andrey Repin wrote: > > Greetings, Corinna Vinschen! > > > > > I toyed around with the Microsoft Account a bit more. And here's why > > > the primary group SID being identical to the user SID is not a good > > > idea: > > > > > Security checks. > > > > > For instance: > > > > > $ echo $USER > > > VMBERT8164+local_000 > > > $ screen > > > Directory /tmp/uscreens/S-VMBERT8164+local_000 must have mode 700. > > > > > Huh? > > > > > $ ls -l /tmp/uscreens/ > > > total 0 > > > drwxrwx---+ 1 VMBERT8164+local_000 VMBERT8164+local_000 0 May 7 12:44 S-VMBERT8164+local_000 > > > > > Uh Oh. > > > > I concur. > > But mostly because of blind check "if it's not 700, it's wrong". > > No, it's not wrong, you dumb piece of code, it's your check isn't right. > > No, the check is right from a POSIX POV. How is a POSIX application > supposed to know that the group with gid 12345 is in fact the user > with the uid 12345? That's not possible in a POSIX environment. > > > > This will be a problem with other security sensitive applications, too. > > > Sshd comes to mind. > > > > > So I guess we really should make sure the primary group SID is some > > > valid group, not the user's SID. > > > > > "None" is not an option since it's not in the user token group list. > > > > > "Users" seems to be the best choice at first sight. > > > > For local SAM account. > > ...or "Domain Users" for AD accounts, probably. AFAICS, domain accounts don't matter. You can connect your domain account to a Microsoft Account, but its token will reflect the domain settings exactly. So, AFAICS, only local accounts are affected at all. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-07 11:57 ` Corinna Vinschen 2014-05-07 12:40 ` Corinna Vinschen 2014-05-07 14:05 ` Andrey Repin @ 2014-05-07 14:05 ` Chris J. Breisch 2014-05-07 14:35 ` Corinna Vinschen 2 siblings, 1 reply; 42+ messages in thread From: Chris J. Breisch @ 2014-05-07 14:05 UTC (permalink / raw) To: cygwin Corinna Vinschen wrote: > On May 6 14:22, Chris J. Breisch wrote: >> Corinna Vinschen wrote: >>> On Windows, users and groups are identified not by uid/gid, but by >>> their SID. The SID is a unique value, but other than that, a SID can >>> be a user or a group and in lots of cases Windows doesn't care. >>> A group can be owner of a file and a user can be the group of the file, >>> it just doesn't matter to Windows. >>> >>> The permission "problem" you're seeing is a result of that. Your user >>> *and* your primary group are both your user's SID. Therefore the same >>> account is user and primary group at the same time. Therefore, if >>> the file is created, it gets created with an ACL with user and group >>> being the same account. Therefore the POSIX translation of the user >>> and group permissions on the file are always the same. >>> >>> Does this clear it up? >> Yes, that makes complete sense. Thank you again. > > I toyed around with the Microsoft Account a bit more. And here's why > the primary group SID being identical to the user SID is not a good > idea: > > Security checks. > > For instance: > > $ echo $USER > VMBERT8164+local_000 > $ screen > Directory /tmp/uscreens/S-VMBERT8164+local_000 must have mode 700. > > Huh? > > $ ls -l /tmp/uscreens/ > total 0 > drwxrwx---+ 1 VMBERT8164+local_000 VMBERT8164+local_000 0 May 7 12:44 S-VMBERT8164+local_000 > > Uh Oh. > > This will be a problem with other security sensitive applications, too. > Sshd comes to mind. > Yes, it was when dealing with ssh that I discovered this issue, and was the reason I brought it up. Ssh wants many of its files to be only accessible by the owner, and not any group. > So I guess we really should make sure the primary group SID is some > valid group, not the user's SID. > > "None" is not an option since it's not in the user token group list. > > "Users" seems to be the best choice at first sight. > That's what I've thought from the beginning. > Alternatively we could use the S-1-11-xxx SID of the Microsoft Account. > That would be in line with the idea to have a user-specific primary > group. > I'm not sure how that helps or even would work. Are you talking about creating a group just for Cygwin purposes that wouldn't map to an actual group on the box? Seems like I need to get some more caffeine and go back and reread your attached document from several messages ago. > Thoughts? > > > Corinna > -- Chris J. Breisch -- 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] 42+ messages in thread
* Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) 2014-05-07 14:05 ` Chris J. Breisch @ 2014-05-07 14:35 ` Corinna Vinschen 0 siblings, 0 replies; 42+ messages in thread From: Corinna Vinschen @ 2014-05-07 14:35 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2739 bytes --] On May 7 10:05, Chris J. Breisch wrote: > Corinna Vinschen wrote: > >I toyed around with the Microsoft Account a bit more. And here's why > >the primary group SID being identical to the user SID is not a good > >idea: > > > > Security checks. > > > >For instance: > > > > $ echo $USER > > VMBERT8164+local_000 > > $ screen > > Directory /tmp/uscreens/S-VMBERT8164+local_000 must have mode 700. > > > >Huh? > > > > $ ls -l /tmp/uscreens/ > > total 0 > > drwxrwx---+ 1 VMBERT8164+local_000 VMBERT8164+local_000 0 May 7 12:44 S-VMBERT8164+local_000 > > > >Uh Oh. > > > >This will be a problem with other security sensitive applications, too. > >Sshd comes to mind. > > > Yes, it was when dealing with ssh that I discovered this issue, and > was the reason I brought it up. Ssh wants many of its files to be > only accessible by the owner, and not any group. > > >So I guess we really should make sure the primary group SID is some > >valid group, not the user's SID. > > > >"None" is not an option since it's not in the user token group list. > > > >"Users" seems to be the best choice at first sight. > > > That's what I've thought from the beginning. > > >Alternatively we could use the S-1-11-xxx SID of the Microsoft Account. > >That would be in line with the idea to have a user-specific primary > >group. > > > I'm not sure how that helps or even would work. Are you talking > about creating a group just for Cygwin purposes that wouldn't map to > an actual group on the box? No. As I explained in my mail from yesterday http://cygwin.com/ml/cygwin/2014-05/msg00083.html as soon as you login with your Microsoft account, your user token contains a special SID which connects your local account with the Microsoft Account. It's the account from Windows' whoami /groups which is called "MicrosoftAccount\<your email>" and a SID starting with S-1-11-*. Using the latest Cygwin developer snapshots, you'll see something along thse lines in `id' output: $ id uid=197613(VMBERT8164+local_000) gid=197613(VMBERT8164+local_000) groups=197613(VMBERT8164+local_000),401408(+Medium Mandatory Level),555(+Remote Desktop Users),545(+Users),14(+REMOTE INTERACTIVE LOGON),4(+INTERACTIVE),11(+Authenticated Users),15(+This Organization),68452(MicrosoftAccount+testuser@foobar.de),113(+Local account),4095(CurrentSession),66048(+LOCAL),262176(+Microsoft Account Authentication) If we use this account as primary group, you would have both, a unambiguous group gid and a user-specific group. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2014-05-09 7:42 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-05-05 13:49 Problem with "None" Group on Non-Domain Members Chris J. Breisch 2014-05-05 13:59 ` Corinna Vinschen 2014-05-05 14:17 ` Chris J. Breisch 2014-05-05 14:47 ` Corinna Vinschen 2014-05-05 15:23 ` Chris J. Breisch 2014-05-05 15:42 ` Corinna Vinschen 2014-05-05 16:17 ` Chris J. Breisch 2014-05-05 16:57 ` Corinna Vinschen 2014-05-05 18:52 ` Robert Pendell 2014-05-06 13:02 ` Corinna Vinschen 2014-05-05 18:56 ` Chris J. Breisch 2014-05-05 19:44 ` Larry Hall (Cygwin) 2014-05-05 21:57 ` Chris J. Breisch 2014-05-05 22:07 ` Chris J. Breisch 2014-05-05 22:29 ` Larry Hall (Cygwin) 2014-05-05 22:39 ` Chris J. Breisch 2014-05-06 0:43 ` Larry Hall (Cygwin) 2014-05-06 12:23 ` Chris J. Breisch 2014-05-05 22:09 ` Larry Hall (Cygwin) 2014-05-06 12:52 ` Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) Corinna Vinschen 2014-05-06 12:55 ` Corinna Vinschen 2014-05-06 13:01 ` Corinna Vinschen 2014-05-07 12:26 ` vlado99 2014-05-07 12:43 ` Corinna Vinschen 2014-05-06 17:01 ` Chris J. Breisch 2014-05-06 17:16 ` Corinna Vinschen 2014-05-06 18:22 ` Chris J. Breisch 2014-05-07 11:57 ` Corinna Vinschen 2014-05-07 12:40 ` Corinna Vinschen 2014-05-07 14:09 ` Chris J. Breisch 2014-05-07 14:46 ` Corinna Vinschen 2014-05-08 20:09 ` Corinna Vinschen 2014-05-08 23:18 ` Robert Pendell 2014-05-09 0:12 ` Ken Brown 2014-05-09 1:34 ` Robert Pendell 2014-05-09 6:11 ` Achim Gratz 2014-05-09 7:42 ` Corinna Vinschen 2014-05-07 14:05 ` Andrey Repin 2014-05-07 14:20 ` Corinna Vinschen 2014-05-07 14:43 ` Corinna Vinschen 2014-05-07 14:05 ` Chris J. Breisch 2014-05-07 14:35 ` 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).