cvs commit: src UPDATING (initgroups)

Brooks Davis brooks at one-eyed-alien.net
Mon Dec 15 09:51:34 PST 2003


On Mon, Dec 15, 2003 at 10:30:18AM -0500, Robert Watson wrote:
> 
> 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. 

This seems reasionable.  My main concern is that we shouldn't make
changes with this kind of impact unless there's a significant security
concern.  Since the general feeling is seems to be that this isn't
significant, we need to ship a minimum of one stable release with a
warning before making the change as it is now.  Leaving things as is it
probably ok in current.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20031215/bbbdc304/attachment.bin


More information about the cvs-src mailing list