Subject: Re: Links and Security
To: eric richard haszlakiewicz <email@example.com>
From: Rick Byers <firstname.lastname@example.org>
Date: 06/08/1997 17:55:55
On Sun, 8 Jun 1997, eric richard haszlakiewicz wrote:
> > 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<
Nope. A hard link is just another directory entry to an allready existing
inode. The user/group information is stored in the inode, so the link has
to belong to the same person as the original file. Sym-links on the
other hand do belong to whoever creates them, but they are just pointers,
not real files (they don't take up much disk space themselves, and the
original file's link-count doesn't get incrememnted).
> > 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.
I'm thinking more along the line of hard links. Sym-links are different,
and not as much as a problem. As you mentioned they are just pointers,
and you can make a sym-link to a non-existant file. However, hard links
are the real problem. They aren't pointers - but just another directory
entry for the same inode - so once they have been created, you can't tell
who actually made the link (owner is owner of original file).
> > 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.
Maybe, but there are still problems elsewhere. Try it out. From your
home directory, do:
ln /some/other/guys/file newfile
you now have a file in your directory that someone else owns, and they
don't know about, and they can't delete it! It doesn't seem right to me
to ever be able to create a directory entry under a different user than
who you are.
I guess changing sym-link behaviour could be a bad idea, but it's hard
links that I'm most concerned about...
Rick Byers Internet Access Worldwide
email@example.com System Admin, Tech Support
Welland, Ontario, Canada (905)714-1400