Subject: Re: Addition to force open to open only regular files
To: NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
From: Bill Studenmund <wrstuden@zembu.com>
List: tech-kern
Date: 11/17/2000 12:04:49
On Thu, 16 Nov 2000, Greg A. Woods wrote:
> As Warner has already pointed out, lots of the world already does
> without this dangerous feature and they don't seem too unhappy about it
> going missing....
We have the report of one person that it hasn't stirred up much concern.
Which could quite be correct. That doesn't mean that if we think we can
get this feature back _safely_ we shouldn't.
> Whether some NetBSD developers might find it inconvenient or not is
> really of no concern of mine, and whether or not they ignore me isn't
> really a big issue to me either. Hopefully those who don't have some
> vested interest in $HOSTALIASES will consider my thoughts on the higher
> level issues and debate their pros and cons and not get distracted by
> this particular example feature which has spurred this discussion.
>
> I'm very much against an open_reg() or open_type() system call in the
> manner of the one proposed at the start of this particular thread, but
> I wouldn't quibble much about an open_as() call, especially if it found
> support in other systems and maybe even standards bodies.
Well, you're welcome to your opinion. But the start of this thread was not
a new open_reg() system call but a new flag to open(2) to open only
regular files.
The difference is that if we were going to change the footprint to the
open call (add a new open-equivalent call), then I agree we should
probably do something like open_as(). But there is a desire to not make
that big a change. Which is why O_REG_ONLY was made.
Also, there's a desire to do something which we can add to 1.5. It's too
late for 1.5 itself, but it's easier to add an open flag to 1.5.1 than a
new system call.
> I'm not sure it needs to be generalised over other file related calls,
> or not (and if so then indeed it may make sense to hide it within a file
> access credential).
>
> I'm not even sure anything new is necessary if set-ID programs are
> kept small and used carefully....
Maybe not for a set-ID program, but for a library routine used by
potentially set-ID programs, a lot of us think something new is needed.
Take care,
Bill