Messages in this thread |  | | Date | Fri, 13 Dec 1996 15:54:42 -0500 (EST) | From | Dan Merillat <> | Subject | QUOTA |
| |
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.
QUOTAS.
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?
--Dan
|  |