>2. Hard links across directories are not permitted. Jan explained that
>security is an issue here.
>
>I think there is wrong thinking in the way Unix does things normally and
>the security argument goes away when the following reasoning is followed.
>
>Unix pretends a hard link is merely a modification of a directory. Of
>course it does add a name to new directory but it also subtly alters the
>attributes of the file in question, since it raises the file's link count.
>
>A perfectly acceptable fix for the (many) problems with link are to permit
>links only if:
>
> - the process can write to the target directory
This is just enforced of course.
> - process can modify the attributes of the file it wants to link
This must be enforced to achieve security (also the very silly quota issue
will be addressed), I agree with you. I agree to change this. I also don't
think the breakage would be noticeable in real world.
>This would work fine in Coda and also solves the problem that arise from
>people keeping hardlinks to insecure suid programs, since they normally
>cannot change their attributes.
Yep. I was just going to suggesting you this after I read you was
concerned about security and you disabled hard links in first place.
Hard links are incredibly useful and it make no sense to disable them only
for security issues as security can be addressed by forbidding changing
the inode->i_link by users that can't change all other fields of the
inode.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/