Subject: Re: Addition to force open to open only regular files
To: NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 11/17/2000 17:37:59
[ On Friday, November 17, 2000 at 12:04:49 (-0800), Bill Studenmund wrote: ]
> Subject: Re: Addition to force open 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.

I don't think O_REG_ONLY, O_RGONLY, or whatever will sovle the problem
sufficiently.  It works now, today, with devices, but as someone's
already mentioned, what about symlinks (I don't recall seeing a real
answer to that question yet).

> 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.

If it's deemed safe to use this kind of test to determine if a process
is running set-ID:

	if ((geteuid() == getuid()) && (getegid() == getgid())) {
		/* process is not running set-ID */
	}

then I'd say throw that in to the resolver code around the code that
implements $HOSTALIASES (and maybe $LOCALDOMAIN), and that'll be it.

That's about the safest and easiest thing that can be done in the short
term I think.

> 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.

Is there really any difference between code directly in a set-ID program
and code in a library routine called by a set-ID program?  There
shouldn't be -- programmers have to be equally aware and careful in both
cases.

In this case the library routine is probably in high-enough demand that
it must take the safe road and not implement any features that might be
dangerous to a set-ID program.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>