cvs commit: src UPDATING (initgroups)

[Robert Watson]

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 at fledge.watson.org      Senior Research Scientist, McAfee Research