Subject: Re: O_REG_ONLY, O_NOFOLLOW, open_ass(), and other such beasts
To: None <tech-kern@netbsd.org>
From: Lucio De Re <lucio@proxima.alt.za>
List: tech-kern
Date: 12/06/2000 06:32:03
On Tue, Dec 05, 2000 at 07:27:38PM +0000, Charles M. Hannum wrote:
>
> Does anyone have further comments on this subject?
>
I do.
Firstly, thanks, Charles, for the very clear exposition. I knew
somebody would get the full picture, I didn't know it could be
illustrated so clearly and succintly for those of us who didn't
:-)
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.
By set?id(get?id()), I mean the operation that forces the effective
id to be the same as the real id _and_ removes any trace of other
possible effective ids. I think _this_ is what set?id(get?id())
does, but sometimes I wonder, please substitute the right thing
herein.
In the context of dynamic linking, I'm not sure how effective my
suggestion might be, so I may be asking a bit much, but I think
the idea deserves airing, even if only to be shot down.
From here, my preference would be to do this to the default runtime,
but compatibility demands that it be made optional, hopefully with
a simple mechanism to bring it into operation.
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.
In practice, the problem with setid shell scripts was resolved by
more or less forbidding them (I seem to recall early Korn shell
documentation to the effect that the Korn shell would (hoped to,
more likely) do the right thing if setuid(root) - I still have some
old document, I'll have a look soon, maybe I should ask David Korn
himself).
I feel we should seek a procedure to couple the chmod ?+s operation
to something inherent in the executable, but until such is found,
set?id(get?id()) will protect us against accidents.
Or am I missing something?
++L