Re: Problem with "None" Group on Non-Domain Members

[Robert Pendell <shinji+cygwin@elite-systems.org>]

On Mon, May 5, 2014 at 12:57 PM, Corinna Vinschen wrote:
> 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 ;)
>>
>> 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.
>>
>> >
>> >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.
>>
>> Bingo. I had just such an account already. It works as expected,
>> i.e. correctly.
>>
>> 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.
>>
>> >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...
>>
>> 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 0x2190
>>    65   36767 [main] chmod 5536 cygsid::debug_print: alloc_sd: owner SID = S-1-5-21-3514886939-1786686319-3519756147-1001 (+)
>>    70   36837 [main] chmod 5536 cygsid::debug_print: alloc_sd: group SID = 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
>

I just saw this thread.  I'm running Windows 8.1 Update 1 and I'm
using a Microsoft Account as login.  I'm seeing the same behavior on
my machine as well with Cygwin64.  I'm open to any tests that you
would like me to do as well.

--
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