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