On Fri, 17 Nov 2000, Greg A. Woods wrote:

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

Adding O_REG_ONLY support does not claim to fix symlink redirection
attacks. The answer to that is open(path, O_REG_ONLY | whatever,);
fstat(); close(); swap IDs; open(path, O_REG_ONLY | whatever); fstat();
swap back, and compate the fstats.

> 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 effectivly what we have (there is an issetugid() syscall) now, and
what we want to change.

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

The difference is not that it can be less aware, but that it has no idea
what has happened to the ids - it can't assume it is running at lower
privileges, whereas a set-ID program should have a good idea what
privileges it is running at.

Take car,e

Bill