Date: Wed, 24 Apr 2002 10:27:42 +0700 From: Alexey Dokuchaev <danfe@regency.nsu.ru> To: Mike Barcroft <mike@freebsd.org> Cc: "M. Warner Losh" <imp@village.org>, nectar@freebsd.org, phk@critter.freebsd.dk, wollman@lcs.mit.edu, cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_descrip.c kern_exec.c src/sys/sys filedesc.h Message-ID: <20020424102742.B96625@regency.nsu.ru> In-Reply-To: <20020423120949.G72727@espresso.q9media.com>; from mike@freebsd.org on Tue, Apr 23, 2002 at 12:09:49PM -0400 References: <20020423104722.D72727@espresso.q9media.com> <20020423152003.GB28750@madman.nectar.cc> <20020423114052.F72727@espresso.q9media.com> <20020423.095226.96600629.imp@village.org> <20020423120949.G72727@espresso.q9media.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 23, 2002 at 12:09:49PM -0400, Mike Barcroft wrote: > M. Warner Losh <imp@village.org> writes: > > In message: <20020423114052.F72727@espresso.q9media.com> > > Mike Barcroft <mike@FreeBSD.org> writes: > > : Yes, at the cost of breaking conforming applications -- even if they > > : haven't been invented yet. I don't have any objections to your hack > > : being left in place until the base system can be audited or even in > > : the long term if its made into a kernel option. > > > > The "it breaks strict standards conformance" is much less important > > than "users are using this standards conformance to leverage higher > > privs." You need a better argument than that if you are going to have > > the changes reverted. Sorry. We already break standards conformance > > for setuid/setgid programs in a number of subtle ways to preclude them > > from gaining higher privs. > > Again, I don't mind this being a kernel option. Even if it's turned > on by default, or we use a reverse kernel option to turn it off. > > A user should be able to choose the security policy of his/her system. > If that means one has to add `option POSIX_SETUGID_HANDLING', that's > fine, but to force a security policy down a user's throat, I think, is > wrong. This applies to Robert's comments as well. <crack-smoking> Actually, it would be interesting to, say, regulate every mentioned (and not) standards violation with a kernel options. Oh wait, we may need just one for that: #options POSIX_COMPLIANT_KERNEL or alike (just substitute ``POSIX'' for whatever standard you prefer ;-) </crack-smoking> Seriously, if we aim to comply to any standard, which had been broken far too many times already, how would one single "kernel option" bring us anywhere closer towards it? Rather then polluting kernel config with dozens of options (that no one is likely to use anyway), why not just get over it and finally decide what we want: a modern, robust and secure operating system that everyone in their mind knows *is* UNIX (no matter what OpenGroup or IEEE says), or have a standards compliant, but potentially vulnerable (in many ways) pile of code? ./danfe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020424102742.B96625>