Subject: Re: Links and Security
To: None <current-users@NetBSD.ORG>
From: eric richard haszlakiewicz <>
List: current-users
Date: 06/09/1997 00:27:02
> I've noticed there are a lot of security issues concerning linked (smy or
> orhterwise) files (tricking a program to write over the wrong file by
> linking it), etc...  I have been unable to think of any situation in which
> you would legitimatly _need_ to link to a file you don't own.  I
	you don't _need_ to be able to do anything.  Being able to create
links can be convenient at times.  For instance, there have been several
times where I've used links to simplify paths I had to type.  This happened
to be for a class where I had to get  to and use files that weren't owned
by me.  

> user could make a directory 700, then link another users files into there.
> When the other user deletes his files, it's still taking up his quota,
> and he can't delete them because he can't get into the directory where
	I thought the links were owned by the creator and thus under >his<
> Is there any great argument against having a kernel option that disables
> linking to files you don't own?  This would stop all the possible security
	What about linking to files that don't exist yet?  It seems like
this would create some rather weird behavior.  You wouldn't be able to 
prevent someone else from putting a file there later.  Also, what if
you happen to be in a chrooted enviroment and create a relative link?  My
idea of a symbolic link (correct me if i'm wrong please) is that it is
simply a path pointer to somewhere else.  Thus I think that blocking the
creation of links would cause problems with non obvious behavior while
running and problems implementing it.  However, if you really want to
do something like this may I suggest checking for non-ownership of the
target of the link at access time.  This would still cut down severely on
the usefulness of links but at least it would be reasonable to check.
There would be no problem with the file not being there, or changing 
ownership at some arbitrary time.  And any calls, such as open could
just fail, maybe saying that whoever opened it didn't have permissions to.

> problems associated with linking /etc/passwd to <you're favourite temp
> file here>, and seems like generally just a good idea to me.  I don't
	hmm... perhaps having /tmp or whatever temp directory on its
own filesystem and just setting this feature on for that would gain most
of the benefit w/o most of the surprise.