This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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":
>> >
>> >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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]