From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10656 invoked by alias); 5 May 2014 18:52:49 -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 10642 invoked by uid 89); 5 May 2014 18:52:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qa0-f41.google.com Received: from mail-qa0-f41.google.com (HELO mail-qa0-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 05 May 2014 18:52:47 +0000 Received: by mail-qa0-f41.google.com with SMTP id dc16so5874411qab.14 for ; Mon, 05 May 2014 11:52:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=GieeHz5O5pZWstyMx810/N+G5qoIitVmfNuXuTHUo9k=; b=PQPIWpa8/L/7uavysiGJov3d3Q6sbjIGituVKjKD4nglozyP1KNjerHCd4YNWMEunv gy/pa0EIz8G/wo6u40sXHnt/Cw9cDlFS+L+ZBOkaHQEjp4bnK/cHo1wcbnv9/nEVkfXg Z+fUiodsXu+Pao6kjz3+TbPGC8JOwtPvApjq66ChezrUkGfJVekZ5H6N6KSYLC2K0slV MD51jGz+8J/cS0u8C6J633A19fiFRZxkeHPlfvyGiwyJmdk52+n8d91YdZXdswc57sFK rUSLoOyLtULI2bLIFsisR5oMC54kpAJSg9YIj98cZj5eJ1hNWwmEhaOzvyzeJbjkPENR sfHQ== X-Gm-Message-State: ALoCoQkXCM0Rv6jzbOKf3as6xiovooIYNxcH3VZhML86l2u6ysdFSwj27SxJHxZgw31b3qvUk0Ic X-Received: by 10.140.104.195 with SMTP id a61mr26564699qgf.102.1399315965173; Mon, 05 May 2014 11:52:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.32.16 with HTTP; Mon, 5 May 2014 11:52:15 -0700 (PDT) In-Reply-To: <20140505165723.GM30918@calimero.vinschen.de> References: <536796E4.2090009@breisch.org> <20140505135928.GK30918@calimero.vinschen.de> <53679D5C.5030209@breisch.org> <20140505144745.GA6993@calimero.vinschen.de> <5367ACED.40409@breisch.org> <20140505154230.GB7694@calimero.vinschen.de> <5367B990.8050907@breisch.org> <20140505165723.GM30918@calimero.vinschen.de> From: Robert Pendell Date: Mon, 05 May 2014 18:52:00 -0000 Message-ID: Subject: Re: Problem with "None" Group on Non-Domain Members To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00068.txt.bz2 On Mon, May 5, 2014 at 12:57 PM, Corinna Vinschen wrote: > On May 5 12:17, Chris J. Breisch wrote: >> Corinna Vinschen wrote: >> >On May 5 11:23, Chris J. Breisch wrote: >> >>In both cases, I am logging on to the machine with a "Microsoft >> >>Account": http://www.microsoft.com/en-us/account/default.aspx >> > >> >Hmm, maybe that's the problem. This "Microsoft Account" stuff might >> >influence how the underlying OS handles permissions. I would never >> >touch this stuff ;) >> >> I don't blame you. And I don't think you can use them on a machine >> that's a member of a domain, but I could be mistaken there. They're >> local accounts, but definitely with a twist. I was pleasantly >> surprised that ssh didn't choke on them, but I didn't really suspect >> it as a root cause for file permission issues, or I would have >> mentioned that in my very first message. >> >> > >> >For testing you could try to create a normal local account, add it to >> >/etc/passwd and run the above under this account. If it behaves >> >differently (correct, that is), it's a something weird with these MS >> >accounts. But then again, I wouldn't know how to "fix" this, other >> >than to suggest to use a normal account instead. >> >> Bingo. I had just such an account already. It works as expected, >> i.e. correctly. >> >> Could we "fix" it by allowing the user to set their default group? >> As I said in my original message, changing the group from None to >> Users in /etc/passwd solved my problems. > > That's exactly how you do it, unless you're already using the new SAM/AD > changes from the Cygwin snapshots, in which case you can override this > in SAM or AD as well. > >> Of course, if we don't really understand these accounts, then we >> don't know why that solved my problem, or if the same thing would >> work for someone else. Hmmm. Never mind. >> >> >Nah, at this point we really don't know why this happens on your machine >> >and it could easily be somebody elses fault. >> > >> >An strace of `chmod 400 bar' might sched some light on this issue, but I >> >have a gut feeling the underlying WIndows call will not even return an >> >error code... >> >> Attached. Your gut seems to be working today... > > There *is* something weird here. Look at this: > >> 151 36702 [main] chmod 5536 alloc_sd: uid 1001, gid 513, attribute 0x2190 >> 65 36767 [main] chmod 5536 cygsid::debug_print: alloc_sd: owner SID = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) >> 70 36837 [main] chmod 5536 cygsid::debug_print: alloc_sd: group SID = S-1-5-21-3514886939-1786686319-3519756147-1001 (+) > > alloc_sd (the underlying function creating a security descriptor) gets > a uid 1001 and gid 513 as input, as usual. But the owner *and* group > SIDs of the file's existing security descriptor is > S-1-5-21-3514886939-1786686319-3519756147-1001, the SID of your user > account. > > Why is your user account the primary group of the file, even though > your user token definitely has "None" (513) as its primary group? > How did it get there? > > Is that something enforced by the "Microsoft accounts", perhaps? > > I just had a look into the Local Security Policy settings, and I can't > see any related setting. > > > Corinna > I just saw this thread. I'm running Windows 8.1 Update 1 and I'm using a Microsoft Account as login. I'm seeing the same behavior on my machine as well with Cygwin64. I'm open to any tests that you would like me to do as well. -- 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