From owner-cvs-all Tue Apr 23 20:28: 6 2002 Delivered-To: cvs-all@freebsd.org Received: from mail.nsu.ru (mx.nsu.ru [193.124.215.71]) by hub.freebsd.org (Postfix) with ESMTP id 7F02E37B417; Tue, 23 Apr 2002 20:27:59 -0700 (PDT) Received: from regency.nsu.ru ([193.124.210.26]) by mail.nsu.ru with esmtp (Exim 3.20 #1) id 170DRW-0008TZ-00; Wed, 24 Apr 2002 10:27:42 +0700 Received: (from danfe@localhost) by regency.nsu.ru (8.11.6/8.11.6) id g3O3Rgg05919; Wed, 24 Apr 2002 10:27:42 +0700 (NOVST) (envelope-from danfe) Date: Wed, 24 Apr 2002 10:27:42 +0700 From: Alexey Dokuchaev To: Mike Barcroft Cc: "M. Warner Losh" , 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> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020423120949.G72727@espresso.q9media.com>; from mike@freebsd.org on Tue, Apr 23, 2002 at 12:09:49PM -0400 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Apr 23, 2002 at 12:09:49PM -0400, Mike Barcroft wrote: > M. Warner Losh writes: > > In message: <20020423114052.F72727@espresso.q9media.com> > > Mike Barcroft 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. 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 ;-) 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