Corinna Vinschen wrote:
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\testu...@foobar.de User
S-1-11-96-3623454863-58364-18864-2661722203-1597581903-2673650909-3269597714-2381787221-1144632321-4110357092
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
passwd: db
group: db
so that you just rely on the new SAM/AD code in Cygwin, you get a
primary group == 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.
Hmmm. Yes, I see that. It seems that the "None" weirdness has just
transferred itself to this other group though. Now my test file is owned
by Chris.Chris instead of Chris.None and the group permissions still
mirror the owner permissions. I dropped my /etc/passwd and am using the
new stuff.
- 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
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.
Thanks,
Corinna
Thanks for looking into all of this.
--
Chris J. Breisch
--
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
