Dan Merillat (Dan@merillat.org)
Fri, 13 Dec 1996 15:54:42 -0500 (EST)

Ok, lets look at the link() problem this way.

In specific, userland binaries that trust what they find in /tmp are broken.
Fixing them is a priority, and changing the way link() behaves just for that
is a bad idea.

Lets move on.


If we say we support quotas then we are going to have to modify the way
things work. For example, we disallow creat() if the user has exceeded
his quota of files. Originally, it was unlimited until the disk space
ran out.

Therefore, as an option of the quota extension to the filesystems, we restrict
link() to the owner of the file. There is really no other way to do it, since
quota is a kernel issue, not a userspace issue. I STILL don't see the harm
in restricting link() access to the owner on a per-filesystem basis.
Usually it won't break anything. _BUT_ what it will do is save your ass if
you don't find out about a security hole before a user on your system does.
Yes, there are buggy programs. YES, they should be fixxed. But, right
this instant, can you certify that EVERY program on your system is TOTALLY
bug free, and will NEVER do something you didn't intend it to? Can you
state, with certanty, that you will recieve news of an exploit before
anyone else in the world? Can you say that you will be able to react
to that news and patch the hole before anyone on your system gets a chance
to use it against you? No, nobody can certify that. So anything that
makes your system more secure WITHOUT breaking anything is by definition
a good idea to implement. And, since we have to implement permission checking
for link() in the kernel anyway (or take out quota support, since buggy
support is worse then none) it should be an option in the general case as well.
NOT the default, but an option.

Besides, nobody should write a program that does a strcpy as root, but many
do. Does that mean that making the stack non-executable (on processers that
support it) is a bad idea?