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=Sk5I0kKibWq8WrBKVJpRkfCWaP0cX2pj59TChJDZsRx6PQkjFOuAb
	UgDew4OrVHRKiqHgTUVRIF/SsjnsqyHEmXfupg+3KNXCnZ+rsLyFaYQRkgpLbWBE
	IYrVxpZx3jTgSBK5qFBcfGZoJeL0YZSDpXNJ3X81dvvYVnXEQMqM5g=
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=nwhyqV1uDCOcg1IYuwEwraA7fvI=; b=OPKOz/dxuYH4h7zCIzO2h1wbzbcB
	WKuWr5/EfzYPBVZjzM5aCat8MfzFKNnuewGAAZBVwmFVbTDJirY4H6FDYScE3ck7
	mFKC3R68x/yolV4WgSZ4Tf1loWoM5cMvuM/ItriMtnOsRFLUVlx2gxU/BA1lJWHJ
	lS9xqMajDrXsmN4=
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:	Wed, 7 May 2014 14:40:38 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members)
Message-ID:	<20140507124038.GG30918@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<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> <53691564 DOT 1070200 AT breisch DOT org> <20140506171626 DOT GZ30918 AT calimero DOT vinschen DOT de> <53692867 DOT 4060305 AT breisch DOT org> <20140507115730 DOT GE30918 AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
In-Reply-To:	<20140507115730.GE30918@calimero.vinschen.de>
User-Agent:	Mutt/1.5.21 (2010-09-15)

--G/vVCphCGw+yuveY
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On May  7 13:57, Corinna Vinschen wrote:
> I toyed around with the Microsoft Account a bit more.  And here's why
> the primary group SID being identical to the user SID is not a good
> idea:
>=20
>   Security checks.
>=20
> For instance:
>=20
>   $ echo $USER
>   VMBERT8164+local_000
>   $ screen
>   Directory /tmp/uscreens/S-VMBERT8164+local_000 must have mode 700.
>=20
> Huh?
>=20
>   $ ls -l /tmp/uscreens/
>   total 0
>   drwxrwx---+ 1 VMBERT8164+local_000 VMBERT8164+local_000 0 May  7 12:44 =
S-VMBERT8164+local_000
>=20
> Uh Oh.
>=20
> This will be a problem with other security sensitive applications, too.
> Sshd comes to mind.
>=20
> So I guess we really should make sure the primary group SID is some
> valid group, not the user's SID.
>=20
> "None" is not an option since it's not in the user token group list.
>=20
> "Users" seems to be the best choice at first sight.
>=20
> Alternatively we could use the S-1-11-xxx SID of the Microsoft Account.
> That would be in line with the idea to have a user-specific primary
> group.
>=20
> Thoughts?

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

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

--G/vVCphCGw+yuveY
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJTainGAAoJEPU2Bp2uRE+giHYQAJKVaFV2Z7Hy0mj/YMEUelKP
/J7+NNP7wGxWsGMiL8sDQtkOIZVRVERrnAwgMy1H5X3BBnaaTxBpPbywy0SeoWUH
rGDF3i/IEEw2I/49u8SSpeJCPWrt9P1PFdiK2PANINtTtgy9mun18nTdKhSU7nYp
OxjzZ8oXkc51NNkYqvYOiFzD2rYbA2M4CkkHggorG5SkbipKft9KecatpQFcmbwc
aeSB+Jg+7F/nJUnU7AmgmplhR6ixZtlGvipc8bqOavrDs1UQmVsrVu7c1CQzfoHV
dSEum/q2k/mees/ICrflPGhp5CJgXmDZJ19zC9KFipSFUFzOybgQlJ/H2PM/yduc
bkoju4J5zNT2u2WvzDjQmRNAG6tW0ZS0lluVuDFwaSZFbVIhBj0dFUCTHyBCbLQ3
jdAJjAhB0+r2/QCFu6ebz12CjEft2vyv3htk+AzqO3//Bjx/HVCBqNBbDrCaj1pq
qf7Ja+rBzLXN48D05z585H/894LuZMZomIJWdiuys0M4vOeVNdqIY0noVNCYj16Q
4/wJhEnzLhwQV3zwgGSg/mcPscbOMYOl1Q0hM8zcEAWnqPLoQZEqVCAcCKAUH1TW
pIDlBO0A7uBoYI9ukqcDSMQQg1VAwI+M7sHy2LIvM/uWKEZPopPxwaxWsV4prcBN
HzsbnpPxDQ0f6v+eK9Pt
=8TBb
-----END PGP SIGNATURE-----

--G/vVCphCGw+yuveY--

- Raw text -