Date: Mon, 15 Dec 2003 09:51:24 -0800 From: Brooks Davis <brooks@one-eyed-alien.net> To: Robert Watson <rwatson@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src UPDATING (initgroups) Message-ID: <20031215175115.GB7002@Odin.AC.HMC.Edu> In-Reply-To: <Pine.NEB.3.96L.1031215102002.89260A-100000@fledge.watson.org> References: <3FDDB797.9080703@freebsd.org> <Pine.NEB.3.96L.1031215102002.89260A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 15, 2003 at 10:30:18AM -0500, Robert Watson wrote: >=20 > On Mon, 15 Dec 2003, Jacques Vidrine wrote: >=20 > > Brooks Davis said the following on 12/14/03 6:57 PM: > >=20 > > > 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 s= hip > > > at least one release with a warning before breaking things since I do= n'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. > >=20 > > 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.=20 > >=20 > > 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.=20 >=20 > It sounds like there's a building concensus here. How about the > following: >=20 > (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). >=20 > (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). >=20 > 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.=20 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 --=20 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 --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/3fSNXY6L6fI4GtQRAsUfAKCSjNXM37aW+X1EgHZzcQmiDUqOJACeJcRa E5DBEY+8z0pbGednhG3RDro= =DnVW -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031215175115.GB7002>