Re: ln weirdness

Floody (
Tue, 25 Mar 1997 10:31:27 -0500 (EST)


On Tue, 25 Mar 1997, Mauro Condarelli wrote:

> > On Mon, 24 Mar 1997, Gerald Britton wrote:
> >
> > > as a normal user, the system lets me do this:
> > >
> > > ln /etc/shadow /tmp/testfile
> > >
> > > it then creates testfile as the same permissions and ownership of
> > > /etc/shadow, thus i still cannot read it, but should it really be
> > > letting me do this? Also, after i create the file, i cannot
> > > remove it (since i do not own it). Should it really be doing
> > > this?
> >
> > I think this was discussed a few months ago, and some onofficial
> > patches were bounced around. IMO, this sort of hard linking should
> > not be allowed. Consider the following:
> >
> > You have sendmail 8.6.x or 8.7.x (aka sendroot). It's suid. You
> > didn't bother partitioning and have /tmp or /home or /var on the
> > same partition as /usr, and some luser hard links sendmail to BitchX
> > in some dir they have write access to. A security bulletin comes
> > out that sendmail 8.whatever has a root compromise (big surprise)
> > and you quickly upgrade and rm that evil old sendmail. The user now
> > has a suid copy of his own to exploit...unless you chmoded the old
> > one before rm'ing it.
> I tought this is exactly why the suid bit is reset whenever you
> modify a file.
> Is ths no longer true ?
> >
> > Of course, most servers probably have several configuration related
> > reasons that the above would fail (logical partitioning, sane mount
> > options), but why should users be able to hardlink files they don't
> > own?
> Best Regards
> Mauro

I, for one, would like to see the hard link security patch integrated into
the kernel tree and a configuration option added which enables it. For
those of us who are security conscious, there is really no reason to
allow users to hard link other user's files (with the exception of root,
of course).

Regardless of setuid being cleared upon file modification, the ability to
hard link a root owned file opens up numerous potential security problems,
all over the place; of which only a few have likely been discovered.

+ -- Finger: for my PGP public key -- +

Version: 2.6.2