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
