X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; q=dns; s=default; b=bF013VOZFYwM6HlyZDSxaIb97MuqGzNOnRWBc2/G3DO K43JkeVhwtnwNJy+O17a4kEDIVE+b3UYkTF7ocZnqEkURVy6OPcxI7ofKGT1zqbc rrKnLA4kx78rkdM9wjTXW/uJ0g5U6YKqDdCe4N2ShXH6jdDHWWiNzaqdcLPg6XEE = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; s=default; bh=kRiPpTwk7Ph/xdNogqLBLofuQpo=; b=aubfb5c27uLLTmnaV Dl+kJKxyqOkLEmwaT5mtnk1h2nu1OnLdDC+4nKPEnBSqx8rponl7xJRA1PtcLOWS cnpjTHACDFxVi/OEhhVBlhuXNro2y21rVslOgAcMlhbCRq0KvRx132GIsPS3pfm5 ejMw0YsLIaYooZf9cd9EZG4dtM= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ig0-f176.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Xs9Rup8a9ExrS0mB69wajTOf0J/2Je4BV5y+tcaFEEo=; b=fFIf3syguL/JkmooWoUIao3jOfDlZ4hl9ejgvnaEYCQMG00GCAu7bxh9kiTma5h+Ku NrweRp3zBOYfnBDkbKPKwKVpKMqZ/EQER5tbuH23Y41O8118TsJLjIm910xpq4//VZqN 4I29r0C6VcNn+f+CPjz70jPV6i60Bo4qXw50WcRkviIwpx/O4bhI9Xptr84LdkCxgQJf uhguQgInISuOfPpSnKQ9X8kJggd5FGflFYlAsh/ae07CNcQuIuUCpQMEHBeprT6IgGEt 0P2iqaZzs/nFFg0OEH06Eg8s33AWfRo/EF5eC8Qvx5azu4gL8kZqB2TceCIUQ8vJ9/kU Cpxg== X-Gm-Message-State: ALoCoQmmkoXZkWVXThDaHAMe1IGcxeM/FVq1ApRofxlOFrKxxz9/tU5Rrz6pp1eTq2hs5cxelAyE X-Received: by 10.50.57.109 with SMTP id h13mr34009360igq.3.1399395687521; Tue, 06 May 2014 10:01:27 -0700 (PDT) Message-ID: <53691564.1070200@breisch.org> Date: Tue, 06 May 2014 13:01:24 -0400 From: "Chris J. Breisch" User-Agent: Postbox 3.0.9 (Windows/20140128) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members) References: <536796E4 DOT 2090009 AT breisch DOT org> <20140505135928 DOT GK30918 AT calimero DOT vinschen DOT de> <53679D5C DOT 5030209 AT breisch DOT org> <20140505144745 DOT GA6993 AT calimero DOT vinschen DOT de> <5367ACED DOT 40409 AT breisch DOT org> <20140505154230 DOT GB7694 AT calimero DOT vinschen DOT de> <5367B990 DOT 8050907 AT breisch DOT org> <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> In-Reply-To: <20140506125203.GO30918@calimero.vinschen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Corinna Vinschen wrote: > But, here's the deal. I eventually gave up and created a Microsoft > Account on my W8.1 machine. And this was definitely the right thing to > do, for a couple of reasons: > > - For a start, it uncovered a case-sensitivity bug in my new SAM/AD > account code. > > - In my case `id' showed clearly that in my user token the primary > group is set to my user account itself. I'm using my new SAM/AD > code, so I can see what happens if there are no /etc/passwd and > /etc/group files in the way. > > - This explains why your user account shows up in /etc/group. `mkpasswd > -c' creates the group info from your user token, and the primary group > in your user token is your own user account. > > - The reason that you *seem* to have "None" as primary group is a result > of historical laziness: mkpasswd simply sets the primary gid to 513 > for all local accounts, since that's what it always was so far. > > - The reason that setting your primary group to "None" doesn't really > work (and thus, neither do file group permissions) is the fact that > the "None" group is no longer in the user token's group list. For > kicks, if you call `net user' it still prints > > Global Group memberships *None > > - The reason that setting your primary group to "Users" works fine > is the fact that it *is* in the user token's group list. > > - One account in the user token's group list is a special SID for a > user(!) account which apparently connects your local account with the > Microsoft Account. Here's the output from Windows' own `whoami' tool: > > MicrosoftAccount\testuser AT foobar DOT de User S-1-11-96-3623454863-58364-18864-2661722203-1597581903-2673650909-3269597714-2381787221-1144632321-4110357092 Mandatory group, Enabled by default, Enabled group > > The problem here is the length of the SID. So far the Cygwin code > assumes that a SID has a maximum number of 8 subauthorities. This is > based on the fact that the Win32 routine to generate a SID allows a > maximum of 8 subauthorities, so it was a relatively safe assumption. > Not so, anymore. The subauthorities are the numbers starting at the > 96. If I count correctly we now have a SID with 11 subauthorities. > > This is, of course, my fault. In reality there's a macro in the > Windows headers called SID_MAX_SUB_AUTHORITIES, which is set to 15. > But so far there were never more than 6 subauthorities, so I never > had a reason to look :| > > As a sidenote, the SIDs of the Microsoft Accounts are undocumented > and no matching values exist even in the latest Microsoft VC++ header > files... > > - The maximum length of a netbios domain name is defined as DNLEN > in lmcons.h. DNLEN is 15. The new domain name "MicrosoftAccount" > has a length of 16. Cygwin uses buffers based on DNLEN :-P > > That's the state for now. I patched Cygwin to be able to handle all of > the above, but I didn't touch the primary group in the user token yet. > > So, if you download the today's developer snapshot from > http://cygwin.com/snapshots/, you get at least a somewhat sane > behaviour: > > - If you have no passwd/group files (or set /etc/nsswitch.conf to > > passwd: db > group: db > > so that you just rely on the new SAM/AD code in Cygwin, you get a > primary group == your user account. The output of `id' reflects > what I wrote above. You will see a group called > MicrosoftAccount\ as part of the supplementary > group list. Hmmm. Yes, I see that. It seems that the "None" weirdness has just transferred itself to this other group though. Now my test file is owned by Chris.Chris instead of Chris.None and the group permissions still mirror the owner permissions. I dropped my /etc/passwd and am using the new stuff. > > - If you still use your current /etc/passwd, you will still have the > "None" weirdness perhaps, because the group with gid 513 is simply > not in your user token, and there's nothing Cygwin can do about that. > > - If you want to utilize Cygwin's capability to override your > primary group, you have two choices: > > - Download the complete cygwin-inst-20140506.tar.xz for your platform > (x86/x86_64) and use the new mkpasswd and mkgroup tools in there > to generate new /etc/passwd and /etc/group files. Then override > your primary group with the value 545, just like before. > > - Alternatively, change the primary group in the Windows SAM, as > described in the document attached to this mail. It's the latest > version of the preliminary documentation of the new account handling > in Cygwin. See the chapter "Cygwin user names, home dirs, login > shells". > > Other than that, I'm open to discuss the necessity(?) to override > the primary group by default. But, in fact, I'm not sure this really > makes sense. Linux systems default to creating a user-specific group > account and using that as the user's primary group for years. The > Windows Account technique isn't quite as nice, but admittedly, it > does its job just as well. Yes, I've experienced that on Linux, but I don't recall having these file permission issues there. Perhaps I just never noticed though. > > Thanks, > Corinna > Thanks for looking into all of this. -- Chris J. Breisch -- 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