Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Jun 2007 17:35:39 -0400
From:      Mike Meyer <mwm@mired.org>
To:        Stanislav Sedov <stas@FreeBSD.org>
Cc:        freebsd-hackers@FreeBSD.org, timur@gnu.org, freebsd-arch@FreeBSD.org
Subject:   Re: setegid bug
Message-ID:  <18024.31275.733694.236655@bhuda.mired.org>
In-Reply-To: <20070607213650.c02130bf.stas@FreeBSD.org>
References:  <20070607213650.c02130bf.stas@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In <20070607213650.c02130bf.stas@FreeBSD.org>, Stanislav Sedov <stas@FreeBSD.org> typed:
> Recently several FreeBSD samba users reported a scary problem with
> samba (http://bugzilla.samba.org/?id=3990). Further research in
> cooperation with Timur Bakeyev (timur) showed, that we have a little
> problem with setegid implementation. In FreeBSD (and even in
> 4.4BSD-Lite2) egid of the process is merely groups[0], so calling
> seteuid function we simply override the first of supplementary groups.
> However, POSIX says that not rgid, not any of supplementary groups
> should bot be rewritten in setegid call.
>
> Probably, some of old-school committers remembered the initial
> intention of making egid equal to groups[0]? Probably, I have missed
> something?

The old school in this case is UC Berkeley. I found this behavior in
4.1BSD. Since it lets you violate ass-backwards group security
settings (wherein you create a group "undesirables", and have files
owned by that group with group bits 0 to keep them out) by removing
yourself from that group, I reported it as a security bug to
CSRG. Mike's response was that the security model was the bug, not
this problem.

I suspect it was done that way in the initial implementation, and
nobody has ever felt that it should be fixed.

	<mike
-- 
Mike Meyer <mwm@mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18024.31275.733694.236655>