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=Z0/pawCOzDBqkj8i8TzldBb97W7Wvbja/Zvcs3DNPNDzpuHf0Zjtb
	GafuHXaW/7r6JZcx6+wejWBmQnhj+Yn+pi5PlYATO9gwKXJVi3U53C7wYg4A9DsV
	lMc67sSdrkOFYogbfgLkP8lvHefnUi1dN6eUIZMaAmwSI9LkhNkn3s=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Tue, 6 May 2014 14:52:03 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members)
Message-ID: <20140506125203.GO30918@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> <20140505165723 DOT GM30918 AT calimero DOT vinschen DOT de> <5367DEE5 DOT 5010407 AT breisch DOT org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="Cqq5NadOW2RfLMJ/"
Content-Disposition: inline
In-Reply-To: <5367DEE5.5010407@breisch.org>
User-Agent: Mutt/1.5.21 (2010-09-15)

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

On May  5 14:56, Chris J. Breisch wrote:
> Corinna Vinschen wrote:
> >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?
> >
> I don't have a clue. You're the expert. :)
>=20
> The ACLs are a little different between the Microsoft Account and
> the regular local account. But, if anything, it's the regular one
> that looks odd to me.
>=20
> Microsoft Account:
> $ icacls bar
> bar WIN8-VM\Chris:(R,D,WDAC,WO,WA)
>     Everyone:(Rc,S,RA)
>     NT AUTHORITY\Authenticated Users:(M)
>=20
>=20
> Local account:
> $ icacls foo
> foo WIN8-VM\cjb:(R,D,WDAC,WO,WA)
>     WIN8-VM\None:(Rc,S,RA)
>     Everyone:(Rc,S,RA)

No, the local account permissions look entirely correct...

> Why does the local account have None permissions, and not
> Authenticated Users?

...because that's how the POSIX permissions are generated.  They always
consist of an entry for your user, your primary group, and the Everyone
group as the Windows equivalent for the POSIX "other" permissions.

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 <yourusername>' 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-1=
8864-2661722203-1597581903-2673650909-3269597714-2381787221-1144632321-4110=
357092 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
=20=20
    passwd: db
    group: db
=20=20
  so that you just rely on the new SAM/AD code in Cygwin, you get a
  primary group =3D=3D your user account.  The output of `id' reflects
  what I wrote above.  You will see a group called
  MicrosoftAccount\<your email address> as part of the supplementary
  group list.

- 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=20
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.


Thanks,
Corinna

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

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

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

iQIcBAEBAgAGBQJTaNrzAAoJEPU2Bp2uRE+gpo0QAJjlwuAV6VXRGqAhxabElY+L
HJwAy5NEy+6bFZQd1BP2nKOvOCTb2FuJz4yZeexlI+xTBlbqZ3dlSYGRR4u5/BF+
trOkmusIag6eNvpufEvtixDhGeV0EimLWk20eohDxE+HSsy56+8B4z1v8/tMYZrD
171ePbp9H4fXV54Xbpj8fHSLpKizEyixNA6PRvSHwUgPwCqhUS13qlAJHXG+A3Ob
wcbJMXV34P7pG8JCFWgr3shZZbUiNcPJvqc09z2WkKETlsIMev+MgbQIlfiU5TRm
Nv9kV8zNKx25cCcFYRwomQDiciFokqN7ANwChzM140LsyZjElIUbxpnPQF7ft2mk
7nM4v6GLC+1+RlGLFnH7To1dvB5zpCazDrY058kqEKF/fSeTqQwkNmxbik6TGTXt
iqpAbh0Dp8/zyIqUAFqIa27TUhrzUU3XZroh4YiHizGRc18aO9iMMQK/AUX0wNVR
Y+bEsZizh0i9ahWC0hK67RME+imMMHCju6gLxNJNRob8ZLZqQpuaTSeQIUd4Kvta
eTVjzMKvjKPQoSwk0FLvQ3H2g+8KNiphGY59H+Q7fvlgM3aFwa+bZ7ZGa952sw4d
LOMvdmZsvNLTobNkv3N0r0fPPj64Xn+pk1Qaza7dXe2E1tUFGYceLv+reKJ2Srpm
/1O5/GvuRI2oh7jG7ZeX
=zApq
-----END PGP SIGNATURE-----

--Cqq5NadOW2RfLMJ/--