[lkml]   [1996]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Proposal: restrict link(2)

> 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...


 \ /
  Last update: 2005-03-22 13:38    [W:0.088 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site