This is the mail archive of the
mailing list for the Cygwin project.
Re: security.cc: bug report, question and suggestion
- From: Corinna Vinschen <cygwin at cygwin dot com>
- To: cygwin <cygwin at cygwin dot com>
- Cc: "Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>
- Date: Sat, 19 Jan 2002 17:06:21 +0100
- Subject: Re: security.cc: bug report, question and suggestion
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On Fri, Jan 18, 2002 at 07:46:03PM -0500, Pierre A. Humblet wrote:
> The real problem is that following setuid(), the ACL (not default
> ACL) of the impersonation token (which is inherited from the
> default ACL of the process token) makes the impersonation
> token non-accessible by its user
> (normally the user has full access to its token,
> and it seems that setuid() should preserve that).
Hmm, noticed. That shouldn't be too hard to add.
> 1) If setuid(gid) with a gid that doesn't exist, the
> system silently sets the gid to "administrators". That
> is not fail safe!
> The problem is that getgrgid() never fails. It should
> have a flag to tell it whether it should default or not.
> [The default is fine when specifying a SET_ACCESS ACE]
Yes, that's true. That's the typical fallback for unmaintained
passwd and group files. We should probably add a function for
internal access which never returns the fallback.
> 2) my_token isn't closed in create_token()
Thanks for the hint! I applied a patch.
> 3) Why is it necessary to set the PrimaryGroup in the
> process token in setegid()? (That can fail silently).
> Is that field ever read? I thought that PrimaryGroup
> only needs to be set in impersonation tokens, so that
> seteuid() can decide if an existing token can be
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
> 4) If in "cygrunsrv -u user ..." the Cygwin and Windows
> user names differ, then the process will have the wrong
> Entry in passwd (note Cygwin name != Windows name)
> /> cygrunsrv -I test -u mail -e CYGWIN=ntsec -p /a.exe
> Enter password of user `.\mail':
> Reenter, please:
> /> cygrunsrv -S test
> /> head /var/log/test.log
> CYGWIN = ntsec USERNAME = UNDEF UID = 500 GID = 513 PID = 619
> <==INCORRECT UID/GID
Operator error. -u expects the Cygwin user name, not the Windows
user name (it's a Cygwin application...). The wrong UID is caused
by your aforementioned observation that the getpwuid/getgrgid
functions always return a default value :-(
Hum, perhaps I should also change the passwd/group access functions
never to fallback if `ntsec' is on...
Thanks for tracking all this down. I will change the token's
ACL to have TOKEN_ALL_ACCESS for the user (perhaps tomorrow) and
then I'd like to ask you to test your stuff again.
Oh, btw., you're perhaps interested to contribute to Cygwin code?
You're one of the few people actually getting wet feet in my ntsec
code. :-) I would appreciate if somebody would put hands on that
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:email@example.com
Red Hat, Inc.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html