Messages in this thread |  | | From | Keith Rohrer <> | Subject | Re: Proposal: restrict link(2) | Date | Fri, 13 Dec 1996 16:23:35 -0600 (CST) |
| |
> And, to bring this back on topic, the original proposal was to only > allow hard links to files that you have read access to. Unfortunately > that proposal won't affect any of the scenarios you mention in reference > to files that are readable by you. How does the immutable attribute bit fit into all this? For example, one might chattr +i /etc/passwd and patch one's passwd (and friends) to verify the immutable bit (and warn in the security log if it's found missing), remove it, modify the file, and make it immutable again. Presumably you need some sort of locking in passwd anyway, so you shouldn't get false warnings...
Thorough use of this tactic will lead to a "you may have privs, but you have to turn off protection to use them" mentality I seem to recall from VMS days. Proper use of groups and setgid in lieu of setuid (or setuid with a non-root owner) will reduce risks where you don't want to do something quite so drastic. Setuid root, group (not setgid) some admin group, no world privs is also a good thing to do with admin-only programs; unfortunately, semi-conscious programs like pppd throw away superuser status from the setuid bit, rendering this scheme useless.
I'd rather not change the semantics for hard links (though I do think they were invented without quotas in mind) if we don't have to, especially when there are ways to avoid it...
Keith
|  |