[Patch]: Create Global Privilege

Corinna Vinschen cygwin-patches@cygwin.com
Sat Nov 29 23:07:00 GMT 2003

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?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

More information about the Cygwin-patches mailing list