Mail Archives: cygwin/2002/01/19/18:34:03
On Sat, Jan 19, 2002 at 04:52:18PM -0500, Pierre A. Humblet wrote:
> At 05:06 PM 1/19/02 +0100, Corinna Vinschen wrote:
> >On Fri, Jan 18, 2002 at 07:46:03PM -0500, Pierre A. Humblet wrote:
> >
> >> 3) Why is it necessary to set the PrimaryGroup in the
> >> process token in setegid()?
> >
> >No, the primary group is used also to create object DACLs.
> >When setting the PrimaryGroup, even native Windows child
> >processes create file with that group as creator group
> >instead of the default group (e.g. always "None", 513 on
> >standalone machines).
>
> yes, but in Cygwin the setgid() is not really effective until
> the next setuid(). By that time there will be a new token
Uh no, the setgid() is effective immediately, not first when
setuid() is called. Setting the PrimaryToken affects further
creation of any securable object later on. That doesn't mean
I'm really sure if that affects a Cygwin application noticeably...
> anyway. What bothers me is that the call may fail silently (e.g. if
The problem is that in contrast to POSIX the PrimaryGroup is
restricted to the Groups already listed in the access token
of the process. So it will fail if the primary group is set
only for a later impersonation. But that shouldn't matter
then, IMO.
> setgid() is called while impersonation is in effect, access
> to the process token would probably be disallowed).
> Even if the call succeeds, won't Windows use the thread (impersonation)
> token rather than the process token when creating DACLs?
I'm not quite sure if I understand. If the setgid() is made
while a impersonation is active, the setgid() should affect
the impersonation token. That seems to be correct. Changing
the PrimaryGroup in that token shouldn't affect the ability
to RevertToSelf().
> Wouldn't it be safer to always rely on myself->gid to set ACLs
> and only use the PrimaryToken to verify if an existing token
> can be reused?
Good question. However, I don't think it's unsafe to change
the primary group. If it was successful, further securable
objects are created using the correct primary group. If it
wasn't successful, nothing has changed, nothing got worse.
> >Oh, btw., you're perhaps interested to contribute to Cygwin code?
>
> Anything specific in mind? I don't have time to start big projects
> but I am happy to help, the more so when bugs affect me :)
Nothing special. I'd appreciate bug fixes as well as extending
the functionality of the security stuff.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -