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