Re: Proposal: restrict link(2)

Adam D. Bradley (
Sun, 15 Dec 1996 16:04:34 -0500 (EST)

On 15 Dec 1996, Kai Henningsen wrote:

> (Cameron MacKinnon) wrote on 13.12.96 in <>:
> > OK, so I've read the debate about hard links to others' files. Some
> > interesting issues have been raised on both sides. Personally I think
> > that people who are going to be programming suid had better know what
> > they are doing.
> How about doing a library for suid programs, with functions to safely do
> all sorts of stuff?

Like open() and stat() files w/ one syscall, and somehow block the prog
from ever calling strcpy()? Not a bad idea.

Someone mentioned that the UNIX sockets can now securely pass UID etc;
this stirred my memory of the "SUID library" debate (sounded a lot like
the link debate of this week), and the closing suggestion: have a root
daemon handle lots of the more jittery security issues, and eliminate
the need for a program to be setuid to begin with. To mesh it with this
idea, perhaps (to maintain source compatibility) programs that would
"normally" be made SUID could instead be linked against a "libcsecure",
which overrides the iffy functions (file and string handling especially),
virtualizes R/E uid's, and so on...(is this sounding a little like C++

Quite a project, indeed...but it could (a) maintain compatibility and
(b) clear up a lot of concerns about sloppy SUID programing...

Just another wacky idea...


He feeds on ashes; a deluded mind has led him    Adam Bradley, UNCA Senior
astray, and he cannot deliver himself or say,             Computer Science
"Is there not a lie in my right hand?"   Isaiah 44:20      <><