Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members)

[Robert Pendell <shinji+cygwin@elite-systems.org>]

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