This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: [Patch] Allow to disable root privileges with CYGWIN=noroot
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-patches at cygwin dot com
- Date: Sun, 4 Oct 2009 21:57:23 +0200
- Subject: Re: [Patch] Allow to disable root privileges with CYGWIN=noroot
- References: <4A993580.4060604@t-online.de> <20090829192050.GA32405@calimero.vinschen.de> <4A999EC2.2070801@t-online.de> <20090830090314.GB2648@calimero.vinschen.de> <4A9AD529.3060107@t-online.de> <20090901183209.GA14650@calimero.vinschen.de> <20091004123006.GF4563@calimero.vinschen.de> <20091004125455.GG4563@calimero.vinschen.de> <4AC8F299.1020303@t-online.de>
- Reply-to: cygwin-patches at cygwin dot com
On Oct 4 21:08, Christian Franke wrote:
> Hi Corinna,
>[...]
> Unfortunately this does not work for a typical use case: an admin process
> creates a restricted token with standard user rights. The function
> IsTokenRestricted() returns TRUE only if the token contains 'restricted
> SIDs'.
> (http://msdn.microsoft.com/en-us/library/aa379137(VS.85).aspx)
Bummer.
> There is apparently no function to check whether a token is a result of
> CreateRestrictedToken() or SaferComputeTokenFromLevel().
>
> Would'nt it be easier to add a new function
> 'cygwin_set_restricted_token(token)' instead of the test of the token type?
The idea was to avoid another non-standard system call. Maybe you're
right, but we should create another cygwin_internal call instead, like,
say,
cygwin_internal (CW_SET_RESTRICTED_TOKEN, token_handle);
Since you have a copyright assignment in place anyway, would you like
to do that and change the seteuid32 call accordingly? A bool value in
cygheap->user could store the fact that the current external token is
a restricted token. That would simplify the seteuid32 extension
enormously.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat