Date: Mon, 15 Dec 2003 10:30:18 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Jacques Vidrine <nectar@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src UPDATING (initgroups) Message-ID: <Pine.NEB.3.96L.1031215102002.89260A-100000@fledge.watson.org> In-Reply-To: <3FDDB797.9080703@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Dec 2003, Jacques Vidrine wrote:
> Brooks Davis said the following on 12/14/03 6:57 PM:
>
> > I think we should put this in in stable and probably never remove it.
> > I'd defintly object if we removed it before 4.11 because we need to ship
> > at least one release with a warning before breaking things since I don't
> > think this is a security issue. If someone can come up with a way not
> > being a member of a group would be a security issue I'd withdraw that
> > objection and just suggest that we add a special case syslog to stable
> > to avoid confusion.
>
> Some authorization decisions grant access on the basis of what groups
> you are *not* in: the file system, at least, and who knows what
> applications may do.
>
> On the other hand, this change *will* break some sites without
> *actually* having a security impact. I tend to agree with you: this
> should be a loud and clear warning for at least one release before being
> made fatal.
It sounds like there's a building concensus here. How about the
following:
(1) We leave the change in 5.x, since it's still considered a development
branch, and we want new installs on 5.x to have the change "from day
one". It sounds like we produce plenty of graffiti in the logs, but
it wouldn't hurt to do some additional testing and see if there are
some ways we can be particularly noisy when failing a login using
/usr/bin/login and sshd or the like. We carefully document this in
UPDATING, the release notes for 5.3, etc. Include an ERRATA for 5.2
that the change isn't in 5.2, but will be in 5.3 (I believe).
(2) We back the change out of 4.x, or at least, make it configurable and
default to off, but produce the warnings anyway. We maintain that
stance through whatever release follows (4.10 or 4.9.1 depending on
branch movement).
I assume there's not time to change the behavior of 5.2 even to log, but
we might want to see if there's a simple one-line change that will cover
90% of the interesting cases -- i.e., add a two-line change to
setusercontext() so that it syslogs over the problem if it happens,
without changing behavior.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1031215102002.89260A-100000>