Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Apr 2002 13:21:42 +0200
From:      Sheldon Hearn <sheldonh@starjuice.net>
To:        Joseph Scott <joseph@randomnetworks.com>
Cc:        "David O'Brien" <obrien@freebsd.org>, Bosko Milekic <bmilekic@freebsd.org>, 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 
Message-ID:  <52526.1018437702@axl.seasidesoftware.co.za>
In-Reply-To: Your message of "Tue, 09 Apr 2002 18:05:40 MST." <Pine.BSF.4.21.0204091802060.39190-100000@pebkac.owp.csus.edu> 

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52526.1018437702>