From owner-cvs-src@FreeBSD.ORG Mon Dec 15 09:51:34 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5E3C16A4D0; Mon, 15 Dec 2003 09:51:33 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2373543D31; Mon, 15 Dec 2003 09:51:32 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id hBFHpOA7017789; Mon, 15 Dec 2003 09:51:24 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id hBFHpOt6017788; Mon, 15 Dec 2003 09:51:24 -0800 Date: Mon, 15 Dec 2003 09:51:24 -0800 From: Brooks Davis To: Robert Watson Message-ID: <20031215175115.GB7002@Odin.AC.HMC.Edu> References: <3FDDB797.9080703@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: Diomidis Spinellis cc: Brooks Davis cc: src-committers@freebsd.org cc: Jacques Vidrine cc: cvs-src@freebsd.org cc: dds@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src UPDATING (initgroups) X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2003 17:51:34 -0000 --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--