On Wed, 6 Dec 2000, Greg A. Woods wrote:

# [ On Wednesday, December 6, 2000 at 06:32:03 ( +0200), Lucio De Re wrote: ]
# > Subject: Re: O_REG_ONLY, O_NOFOLLOW, open_ass(), and other such beasts
# >
# > Secondly, it has been nagging me for a while that the setid
# > functionality is flawed in an intractable way: it is decoupled from
# > the actual program code by being a property of the i-node, not the
# > executable.
# > 
# > What I want to suggest may not solve any problems, but it will
# > reduce the likelihood of accidents: if normal crts (the runtime)
# > actually were to perform an obligatory set?id(get?id()) before
# > starting main(), it would take linking with a special runtime to
# > activate (well, inhibiting de-activation) of setid executables.
# >
# >[[....]]
# >
# > The issue really remains that it is a trivial system administration
# > task to make an executable setid, which unfortunately does no
# > checking of the reliability in such context of the underlying code.
# > Ideally, one should want a certification suite that all potential
# > setid programs should satisfy before the set?id bits can be set.
# 
# There's certainly lots of merit to the underlying idea that you're
# suggesting here.
# 
# Note that there's already a rudimentary implementation of such a
# "certification" suite in the form of /etc/security and the tools it uses
# to scan the filesystem on a nightly basis.  It's not nearly so
# pro-active as a run-time check, and of course it still leaves all of the
# rope in the hands of the system administrator....

Will you guys please stop trying to save us from ourselves?!?

This set-id thing is getting out of hand in a very big way.  I don't
think that rewriting access/set-id semantics is a win at all.  If you
don't want setuid stuff to run, or you're gonna be that picky about it,
SHUT SETUID OFF, either by chmod or by way of a flag to mount.  But
please don't go remaking the world on a whim.

				--*greywolf;