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