Re: Proposal: restrict link(2)

Illuminati Primus (
Fri, 13 Dec 1996 20:00:45 -0500 (EST)

On Fri, 13 Dec 1996, Dan Merillat wrote:

> On Wed, 11 Dec 1996, Greg Alexander wrote:
> > Date: Wed, 11 Dec 1996 23:00:01 -0500 (EST)
> > From: Greg Alexander <>
> > To: Linux kernel mailing list <>
> > Subject: Re: Proposal: restrict link(2)
> >
> >
> > On Wed, 11 Dec 1996, Hubert Mantel wrote:
> >
> > However, for small code-hackers, who do all sorts of funny things to their
> > systems, finding a single linux partition with all of the files on it is a
> > _very_ common thing. security should not be denied to these systems.
> Well, if you only have one filesystem you have a problem. And small code
> hackers with only one drive generally are not runing highly-secure systems.
> There are some that I know of, but not many.
> > However, I don't think that this is necessarily a kernel issue.
> > If compatability is hoped to be maintained with more "standard" flavors
> > then the commands should probably continue to work basically the same. It
> > presents a problem that can and should be easily solved in userspace.
> _NO_ There are _WAY_ too many buggy programs out there... and unless you
> are willing to be on 20-30 security lists and are quite capible of fixing
> on the spot any program that you are running on your system... not just
> suid stuff, but anything that is called from cron, that is a server, or
> that root may run, then you will need some sort of kernel help on this.
> > Having the kernel take care of everything adds to all sorts of
> > portability/security problems on other platforms. Even the way that some
> Actually, the inability to link to files owned by someone else isn't
> really a major problem... I can't really see any time that you would
> need to link() to a file that you only have read access to. If you
> can write to it (owner/group/other) then you should be able to link to it.
> Besides, by link()ing to a file you change it. And if you don't have the
> ability to write to it, you should _NOT_ be able to change a file.
> symlinks don't count, as they are just pointers to a file that may, or may
> not exist. Hard links become the file itself.
> > of the includes include other stuff automatically for me has proven to be
> > a pain in the butt when trying to port to SunOS (am I seeing funny
> > systems, or is every SunOS system's include files really messed up?).
> > Being able to assume that there are no hardlinks in /tmp that shouldn't be
> > there is not an assumption that I think programs should be able to make.
> All too true. But all too common none the less...
> Would anything BREAK if we made link() depend on write access? And does
> POSIX require that ability?
> NOTE: I'm not saying this should be the default behavior. And nobody can make
> the argument that it 'promotes stupid security errors' Because it dosn't.
> What it _DOES_ is fix the hole that lots of stupid programmers make. And just
> doing a stat() before modifying a file may not be good enough... that does
> leave fairly obvious race conditions. Besides, I don't like the idea of
> someone leaving a program that watches /tmp for "interesting" files, then
> hardlinks them before they get erased... If they can make something permanant,
> they may be able to use something else to get at it. For example, some hole in
> some cron'd process that only execute sonce per hour... what's the odds of a
> password change that puts a copy of /etc/shadow in /tmp happining at the exact
> time that does? But if they can link("/etc/shadowtmp","/etc/mytmp"); then
> they can come back and read it at their leasure...
> Now, like I said, do we _REALLY_ like the connotations of being able to link
> (and therefore modify) files that we don't have write permissions to?
> --Dan

Why not just make link() create a symlink instead of throwing it away
alltogether (yes and i know it might break some weird program somewhere,
but it will do away with your supposed chown() bug)..