* 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 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 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
* 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
* 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: 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: 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: 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: 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 ` Chris J. Breisch
2014-05-07 14:05 ` Andrey Repin
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: 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-07 11:57 ` Corinna Vinschen
2014-05-07 12:40 ` Corinna Vinschen
@ 2014-05-07 14:05 ` Chris J. Breisch
2014-05-07 14:35 ` Corinna Vinschen
2014-05-07 14:05 ` Andrey Repin
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 11:57 ` Corinna Vinschen
2014-05-07 12:40 ` Corinna Vinschen
2014-05-07 14:05 ` Chris J. Breisch
@ 2014-05-07 14:05 ` Andrey Repin
2014-05-07 14:20 ` Corinna Vinschen
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 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: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: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
* 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 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
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 ` Chris J. Breisch
2014-05-07 14:35 ` Corinna Vinschen
2014-05-07 14:05 ` Andrey Repin
2014-05-07 14:20 ` Corinna Vinschen
2014-05-07 14:43 ` 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).