Skip site navigation (1)Skip section navigation (2)
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>