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=lSYAtQ7ui/nawahBoMUyZ0KR+gd8bM0J/nBQkvKnkZ4sKSkaXrMo+
	fgwNQ2V4P4ZrksNUgfRn/SYT/Foa6OZpqqjUu0Y2pPGfXAnL9Gcvl8nVHpcYovZN
	mQdzHoksxr99Ips2X+cQhe9V8C+FPcjohozoaFHltS23gZNr42R+jg=
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=Mlpyv9ypiU+0cQExo4cRUuHGwMw=; b=PLdY/aG9bkySQZQy3FP8aNDjqL0k
	+RuhB/KnKrfujw7EJ8bTEOIhVEJoPbLWt+EkQajUceoPS+ZOurw8oKo3jHpYFJmK
	y6WXkIsD6NWAQNymd2KBhqClrkL8lWWYphcu8O8UR4xUeEj16ggxyxVgAXO6CojD
	VC36lnJ0UIoIvn4=
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 13:57:30 +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: <20140507115730.GE30918@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <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> <53691564 DOT 1070200 AT breisch DOT org> <20140506171626 DOT GZ30918 AT calimero DOT vinschen DOT de> <53692867 DOT 4060305 AT breisch DOT org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="1kVeyRzorzGcO9ta"
Content-Disposition: inline
In-Reply-To: <53692867.4060305@breisch.org>
User-Agent: Mutt/1.5.21 (2010-09-15)

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

On May  6 14:22, Chris J. Breisch wrote:
> Corinna Vinschen wrote:
> >On May  6 13:01, Chris J. Breisch wrote:
> >>Corinna Vinschen wrote:
> >>>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.
> >
> >No, it *is* different,  On Linux you get a user account called "Chris"
> >and a group account called "Chris", and they are different because users
> >and groups are totally different beasts on POSIX systems.  You can have
> >a user with uid 42 and a group with gid 42 and they are still different.
> >
> >On Windows, users and groups are identified not by uid/gid, but by
> >their SID.  The SID is a unique value, but other than that, a SID can
> >be a user or a group and in lots of cases Windows doesn't care.
> >A group can be owner of a file and a user can be the group of the file,
> >it just doesn't matter to Windows.
> >
> >The permission "problem" you're seeing is a result of that.  Your user
> >*and* your primary group are both your user's SID.  Therefore the same
> >account is user and primary group at the same time.  Therefore, if
> >the file is created, it gets created with an ACL with user and group
> >being the same account.  Therefore the POSIX translation of the user
> >and group permissions on the file are always the same.
> >
> >Does this clear it up?
>=20
> Yes, that makes complete sense. Thank you again.

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:

  Security checks.

For instance:

  $ echo $USER
  VMBERT8164+local_000
  $ screen
  Directory /tmp/uscreens/S-VMBERT8164+local_000 must have mode 700.

Huh?

  $ ls -l /tmp/uscreens/
  total 0
  drwxrwx---+ 1 VMBERT8164+local_000 VMBERT8164+local_000 0 May  7 12:44 S-=
VMBERT8164+local_000

Uh Oh.

This will be a problem with other security sensitive applications, too.
Sshd comes to mind.

So I guess we really should make sure the primary group SID is some
valid group, not the user's SID.

"None" is not an option since it's not in the user token group list.

"Users" seems to be the best choice at first sight.

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.

Thoughts?


Corinna

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

--1kVeyRzorzGcO9ta
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJTah+qAAoJEPU2Bp2uRE+gaj0P/3KbE2ZgVhJWWYC489emF4j8
k7BacB9PAdXSEhePejHR/ybW9FJHf9WQKADCS5H7D5MU2BEZrCgFYLn6l5sWh7KI
oYwCKp+fW5YkGJMvPVauqaZNpJKF4S5wgCxUHcoDv/baOLaXNYv7bRgWWSo10CCB
JIFqOmtRH1TMdmuiFFZ5+p0LK1dbA448qWTvp1mMuLJi4ow0iLnzN+uX8eshug/D
kz4e2ZN0as4vPxHBtcgoyo2Z0peKUff0tjywU09qIhKu+chv2RZwTT6BVXFSu4yc
vsGWr3fbWTAdmRn0t3qrqyLlgjTH8bE/4tARW1QiCVifaw7HeSJkxSWj8VJZvuTc
M/6g1IOyUVCGQ3FgsHeWyiOV9IHr6LRrGtNMkcT2WAMc6bZACzH/pXUGZPPa/7xJ
ob13i4n3PwOifUEHngPCXd/1YQTE1/yt8/yW3W9mjznY5XhQRmjJL5tydBFljlIY
Zp/TR+4bJ4NG/WkWiS5WqMkOzEkBIHza87g7pZved+PDzW1OyAON+PBbsXPox4jV
2+kfk+hBTlaWfoFLV7wVT+q8RQH+GUM3HbVyy/4TofP1HVgIiDEzPRldgryB/wur
HkIHMW8BqGseknW3XCD1uzRhWg0WL+jtDMZs/tQoYX8yQXRAjis8FqpU+9KpSnmY
hRA5MsK0sv3uG4PlXcxQ
=VHd5
-----END PGP SIGNATURE-----

--1kVeyRzorzGcO9ta--