From owner-cvs-all Wed Apr 10 4:18:51 2002 Delivered-To: cvs-all@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 025B737B419; Wed, 10 Apr 2002 04:18:35 -0700 (PDT) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16vGAY-000DfD-00; Wed, 10 Apr 2002 13:21:42 +0200 From: Sheldon Hearn To: Joseph Scott Cc: "David O'Brien" , Bosko Milekic , cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/bin Makefile src/share/examples/etc make.conf src/usr.bin Makefile In-reply-to: Your message of "Tue, 09 Apr 2002 18:05:40 MST." Date: Wed, 10 Apr 2002 13:21:42 +0200 Message-ID: <52526.1018437702@axl.seasidesoftware.co.za> 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, 09 Apr 2002 18:05:40 MST, Joseph Scott wrote: > That's an interesting idea. If there was a running list of what's > normally suid then admins could go through and only set suid on programs > of their choice. Provide and commit to maintaining this, and you'll be a hero. > Which of course brings up the question, if NO_SUID is set, should > a port that wants to install a suid program be allowed to? Or should it > ask if you still want to continue with the install? Ug, perhaps a IS_SUID > for ports :-/ The ports tree already has a relatively graceful method of handling setuid stuff, by warning the operator of any setuid (perhaps only setuid root? doesn't matter...) binaries installed. So I don't think whatever you do with this in the base system needs to interact with the ports tree. I'd quite like an ALLOWED_SETUID_PROGS make.conf variable which, if defined, contains a list of binaries which are allowed to be installed with the setuid bit set. That would allow folks who don't define it to get the default set of setuid programs installed. Folks who "opt in" by defining the variable commit to keeping it updated as the base system inherits new setuid programs. That's also a good thing. It's a win win scenario that doesn't require a "list of setuid binaries in the base system" maintainer, although such a person's efforts would still be appreciated regardless, especially if said list included brief descriptions of why the setuid bit was required for each binary and what would break if it were turned off. So there you go; two ideas, each of which requires a volunteer to do some work. Neither of which I'm volunteering to work on. Sponsored by: The Ideas Brigade Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message