This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members)
- From: Robert Pendell <shinji+cygwin at elite-systems dot org>
- To: cygwin at cygwin dot com
- Date: Thu, 8 May 2014 21:34:24 -0400
- Subject: Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members)
- Authentication-results: sourceware.org; auth=none
- References: <20140505165723 dot GM30918 at calimero dot vinschen dot de> <5367DEE5 dot 5010407 at breisch dot org> <20140506125203 dot GO30918 at calimero dot vinschen dot de> <53691564 dot 1070200 at breisch dot org> <20140506171626 dot GZ30918 at calimero dot vinschen dot de> <53692867 dot 4060305 at breisch dot org> <20140507115730 dot GE30918 at calimero dot vinschen dot de> <20140507124038 dot GG30918 at calimero dot vinschen dot de> <536A3E80 dot 2060602 at breisch dot org> <20140507144611 dot GM30918 at calimero dot vinschen dot de> <20140508200947 dot GA2645 at calimero dot vinschen dot de> <CAAeCd-OL1U-9CTTXByWx4voR-uBGrQ7zdWk=FyDoREj7NymRYA at mail dot gmail dot com> <536C1D6C dot 8010908 at cornell dot edu>
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