On Wed, May 7, 2014 at 8:57 AM, Corinna Vinschen wrote: > On May 7 14:22, Corinna Vinschen wrote: >> On May 6 20:49, Corinna Vinschen wrote: >> > On May 6 11:49, Eric Blake wrote: >> > > On 05/06/2014 10:39 AM, Corinna Vinschen wrote: >> > > >> > > > The problem, which I totally not realized since I started implementing >> > > > this stuff is, that by propagating this cache to child processes, said >> > > > child processes suffer from what the parent process does to the passwd >> > > > structures in the cache. >> > > > >> > > > Screen seems to call getpwuid and then sets some of the pointers in the >> > > > passwd structure it got from the call to NULL, apparently for some sort >> > > > of security, this way overwriting the cached passwd struct for the >> > > >> > > Bug in screen. POSIX states: >> > > >> > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/getpwuid.html >> > > >> > > The application shall not modify the structure to which the return value >> > > points, nor any storage areas pointed to by pointers within the >> > > structure. The returned pointer, and pointers within the structure, >> > > might be invalidated or the structure or the storage areas might be >> > > overwritten by a subsequent call to getpwent(), getpwnam(), or >> > > getpwuid(). >> > >> > Oh, wow. However, what if screen (thinks it) never calls getpwuid or >> > getpwnam again. In that case it may do whatever it wants with the >> > pointers inside the returned passwd structure, doesn't it? It certainly >> > doesn't have to expect sharing with another process. >> > >> > > > current user. Ssh on the other hand tries to copy the passwd >> > > > structure, >> > > > but it never checks for NULL pointers because, well, the passwd >> > > > structure never contains NULL pointers. >> > > > >> > > > This annihilates every advantage the cygheap caching has. >> > > >> > > Caching still sounds correct, let's fix the bug in screen instead of >> > > bloating cygwin to work around it. Or maybe find a way to cause a SEGV >> > > in any process that tries to write into the pointer returned by getpwuid >> > > and friends, to help them realize their bug, rather than the current >> > > state of propagating the broken memory to other processes. >> > >> > Hmm, I'd have to allocate a full 4K page for this. Also, ssh called >> > from screen works fine on Linux, even if the above behaviour is buggy... >> > >> > > Maybe you >> > > just memcpy the result out of the cache into local memory, instead of >> > > returning a pointer into the actual cygheap cache. >> > >> > Yes, that's what I was coming to realize, too. I'm going to copy the >> > entire entry to local storage and return a pointer to that. >> >> I created a matching patch. Please give the today's developer snapshot >> from http://cygwin.com/snapshots/ a try. > > I just created another snapshot. The former snapshot had an off > by one bug so the passwd buffer given to the application was one > byte short. Please make sure to try the snapshot with timestamp > 14:55:24 (x86) or 14:55:06 (x86_64). > > > Sorry, > Corinna >
It sounds like the result of using the Microsoft Account connected to a regular account instead of using the regular account directly has both a static and dynamic component. This suggests that the behavior could be modeled by a regular account log in, immediately followed by a chgrp which is dependant on the type of regular account, or some other variation of su and chgrp actions. Doug -- Doug Henderson, Calgary, Alberta, Canada -- 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
