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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=rRhZYARXB49fFRgLw3f3GjEouKl8sGv7nL9Byf7grsWU4jUJMCuKG
	QcPFlDXbnHuuCMZjBgxVdXRCvpiWqMziUoTPgcJs+JloRWZxcfBwUkEllZN3yVZy
	ZFGNH4lOwCPmhOkCRObctFAD0Pz1iFJ74jn79ciUdNtG+hOvfv8/Kg=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=dhiPcRqLF/ak6gexS1IA0xvtuFw=; b=i8KYYIl+bOLygjw2qHX3r8KrBmxQ
	7WDOdrpGhpdBTu5CApfaE95v+ZGY1y7oA0SMdZ/6FhyqCbrEWZEWaSMXqAtN795u
	vD+QeJZtEPUiB9H3JySFbSE3anQhwfjib+fP5NW5QB8hoPc5TBgMW0xNCMHPL/lf
	YRDGYBmQbT0bnuE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO: calimero.vinschen.de
Date: Mon, 5 May 2014 18:57:23 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Problem with "None" Group on Non-Domain Members
Message-ID: <20140505165723.GM30918@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="n83H03bbH672hrlY"
Content-Disposition: inline
In-Reply-To: <5367B990.8050907@breisch.org>
User-Agent: Mutt/1.5.21 (2010-09-15)

--n83H03bbH672hrlY
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 ;)
>=20
> 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.
>=20
> >
> >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.
>=20
> Bingo. I had just such an account already. It works as expected,
> i.e. correctly.
>=20
> 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.
>=20
> >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...
>=20
> 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 0x=
2190
>    65   36767 [main] chmod 5536 cygsid::debug_print: alloc_sd: owner SID =
=3D S-1-5-21-3514886939-1786686319-3519756147-1001 (+)
>    70   36837 [main] chmod 5536 cygsid::debug_print: alloc_sd: group SID =
=3D 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

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--n83H03bbH672hrlY
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTZ8LzAAoJEPU2Bp2uRE+gTvsP/ik3XC92uJ5l1e1UfN8GaGWd
O4jNUDL3ni5ErceKTLFLxObUv0YpkAcu2RofwnLTlSipkD8C+hSDLqo5ksePvnF0
lXlPUrNfrqOhcom8cj7UaTSqVdvuS34mxPbneN9PRVjPGcNCZObaNl6Za5RAIt22
n3FSvWiwqnLnTkILMCLdAouDbxKXzLIegg36TBnxYhstsf3KTNjRvF+hbeW6bnow
BpRjgPYLd0uBf4h3v+FbfqlkS0DsgTEpH7qN+eGvBO1+VuNszuVrE9lVEEMcLG9Y
S19iUrxDIoGzw2bBXN7li0fK4f6hkCT6/1/DXBo1BA9feM01xovD8pTwEfJt37jm
wZ+jNTx3NG/84/Vt1guQfbpDrwnFfFAai2WxHDGS4iBCJiCzAgW7FbELUNUgRO1L
DVepEcjhaJRLePI1ZAAcwocFC/5ciyPkcf/PKUIEBbS4Il6tyt/w9JQxdZIK25KX
BLoNeO1UuUE+PVLkB3wlnw5whnVEy5GTAvFKQzs8eSW9bjePTzidCdn6j0OiNrST
IOwPW785pbCLOeTofDUZmu00JT7lURW7KrvYSSP1mhlxKw07TTMnXAYVmiN1p4wX
Ah4dhKz9rOSqldz6Uw5U8AZK6GE7Npqj/Yz8mnWOZZWFtD610IEC0Aq8WevHiEzU
gflxoDbPXP1fKlBRCmV+
=L4wG
-----END PGP SIGNATURE-----

--n83H03bbH672hrlY--