>such games link() is the least of your problems - it's effect can be
>completely reproduced with plain open(). exec 42</bar/foo and several
>hours after that sh -c /dev/fd/42 will do the trick - fork() preserves
>open descriptors.
If there was really a security hole the intruder could as well exploit the
system and change the kernel at runtime to hide his backdoors and change
the partition table and the lilo executable to continue to patch the
kernel at runtime to continue to provide his backdoors even after the
administrator rebooted or reinstalled a new kernel. That's not the point.
I completly agree with you that the suid hardlink issue is not a good
point for the above issues. Doing >suid is the right thing to do.
But for the quota forbidding the hardlink in such case is a good point
IMHO.
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/