[Patch]: Create Global Privilege
Tue Dec 2 04:06:00 GMT 2003
On Mon, Dec 01, 2003 at 10:55:46PM -0500, Pierre A. Humblet wrote:
>Corinna Vinschen wrote:
>>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
>>> > >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,
>>> > if a user (or a seteuid process) is already running at the
>>> > 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.
>>I've applied the patch which just a minor change to remove the
>>However, I think the right thing to do would be to add prefix to
>>cygheap_init so that it survives exec(2) calls.
>Great Corinna, putting prefix in the cygheap is exactly what I meant to do,
>as discussed earlier in the thread. It wasn't in this patch only to keep
>Below is another small patch to lookup pinfo's in the global name space
One might wonder why I, the author of shared_name, didn't use shared_name
to begin with... I'm pretty sure I had a good reason but it escapes me
at the moment.
>Also, the utmp/wtmp functions use mutexes to insure safe access.
>That creates two problems, particularly on servers:
>- When users have private copies of Cygwin with different mounts,
i.e., an unsupported installation.
>RCS file: /cvs/src/src/winsup/cygwin/pinfo.cc,v
>retrieving revision 1.92
>diff -u -p -r1.92 pinfo.cc
>--- pinfo.cc 28 Nov 2003 20:55:58 -0000 1.92
>+++ pinfo.cc 2 Dec 2003 01:26:54 -0000
>@@ -147,7 +147,7 @@ pinfo::init (pid_t n, DWORD flag, HANDLE
> int created;
> char mapname[CYG_MAX_PATH]; /* XXX Not a path */
>- __small_sprintf (mapname, "cygpid.%x", n);
>+ shared_name (mapname, "cygpid", n);
> int mapsize;
> if (flag & PID_EXECED)
More information about the Cygwin-patches