On Sun, Nov 30, 2003 at 12:07:22AM +0100, Corinna Vinschen wrote: > On Wed, Nov 26, 2003 at 10:45:57AM -0500, Pierre A. Humblet wrote: > > At 03:32 PM 11/26/2003 +0100, Corinna Vinschen wrote: > > >Imagine a sshd service is running on the system. This service has the > > >SE_CREATE_GLOBAL_NAME privilege and would create the global object on > > >system startup (given the service is in automatic mode). Other processes > > >would then be able to access the global object, regardless if running in > > >a terminal session or not. This would keep the process list together, > > >for instance. > > [...] > > The problem with the track you start on is that one can end up with a > > split system, e.g. the cygwin share in global space and a tty in local > > space, invisible to the rest of the system. I am unsure of what can > > happen then. Also the user share could be either global or local, depending > > if a user (or a seteuid process) is already running at the console/service > > at the moment a session starts under Terminal Services. > > That leads to indeterminate behavior. > > If we make sure that the first process started in a process hirarchy > determines where the shared mem is, that shouldn't be a problem. The > decision should be made only once. > > > >Also, shouldn't the prefix variable have a NO_COPY attribute? If the > > >process setuids and forks, the new process might have different privileges > > >which might or might not result in the need to use a different object > > >name space. > > > > I think it's OK. forks don't call CreateProcessAsUser and memory_init happens > > early. However I am not 100% sure of what might happen following a seteuid > > (but it won't be worse than before the patch). > > My above comment would support the NO_COPY, wouldn't it?
Gosh, no, it doesn't. I shouldn't try to think when it's that late. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:[EMAIL PROTECTED] Red Hat, Inc.
