From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1009 invoked by alias); 9 May 2014 00:12:40 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 981 invoked by uid 89); 9 May 2014 00:12:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: limerock03.mail.cornell.edu Received: from limerock03.mail.cornell.edu (HELO limerock03.mail.cornell.edu) (128.84.12.34) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 May 2014 00:12:38 +0000 Received: from limerock04.mail.cornell.edu (limerock04.mail.cornell.edu [128.84.12.60]) by limerock03.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id s490Ca3q019978 for ; Thu, 8 May 2014 20:12:36 -0400 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock04.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id s490CaBK010997 for ; Thu, 8 May 2014 20:12:36 -0400 Received: from [172.160.101.120] (50-192-26-106-static.hfc.comcastbusiness.net [50.192.26.106]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id s490CYOh009119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 8 May 2014 20:12:35 -0400 Message-ID: <536C1D6C.8010908@cornell.edu> Date: Fri, 09 May 2014 00:12:00 -0000 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) References: <20140505165723.GM30918@calimero.vinschen.de> <5367DEE5.5010407@breisch.org> <20140506125203.GO30918@calimero.vinschen.de> <53691564.1070200@breisch.org> <20140506171626.GZ30918@calimero.vinschen.de> <53692867.4060305@breisch.org> <20140507115730.GE30918@calimero.vinschen.de> <20140507124038.GG30918@calimero.vinschen.de> <536A3E80.2060602@breisch.org> <20140507144611.GM30918@calimero.vinschen.de> <20140508200947.GA2645@calimero.vinschen.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00170.txt.bz2 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 -- 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