On Thu, May 8, 2014 at 8:12 PM, Ken Brown <kbr...@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
