Shachar Shemesh wrote:
> Hi all,
>
> Does anyone know WHY only root can create hard links to directories?
> What is the attack/problem this permission restriction is trying to solve?
link(2) and unlink(2) are very limited, probably because somebody was
too lazy or too paranoid.
Originally, in the earliest UNIXes, there was no mkdir(2); Instead, the
mkdir(1) called creat(2) with file permissions of a directory, and then
used link(2) to link the directory to "itself/.", and to link the
parent to "itself/.." ("itself" = the new dir, not the parent).
rmdir(1), too, used a long way:
unlink("/path/."); unlink("/path/.."); unlink("/path");
Of course, nobody prevented you from unlinking("/path") directly, but
then you produced two orphan links, and a conflict between the link
count in the inodes and the real count. Moreover, the inode of the
removed directory was not really removed.
Then the mkdir(2) and rmdir(2) system calls were introduced, but you
still had to call the link(2) syscall twice, to create the "." and ".."
links (we are still in the 70's, some of you were not in the plan
yet...).
While the ln(1) command prevented users (including super-users) from
doing dangerous things, direct calls to link(2) and unlink(2) could do
everything: removing the "." or "..", linking another directory (or even
a file) to them, creating environments that could cause the pwd(1)
command to crash ("cd kuku; unlink ..; link . ..; pwd"), etc.
Of course, doing such things caused fsck to complain. On the other
hand, super-user can do everything, even if you block this specific
thing, because after all, he can even open the entire filesystem as an
image and manipulate it, so why should we prevent him from running such
system calls?!
Still, we can't allow normal users to do such things, that may create
infinite recursions, filesystem integrity issues, etc.
Later, in modern systems, including Linux, the functionality of
mkdir(2) was expanded, and it created the "." and ".." too, with no
need for a separate "link(2)" calls.
link(2) and unlink(2) could be implemented in a way that could be less
limited, but still be safe enough. Instead of preventing everything,
it could be more selective. For example, prevent manipulation of "."
and ".." links. Or preventing linking from directories (or files!)
which are not owned by you (otherwise, one can link a system directory
to a temporary directory which is cleaned up by a setuid-on-exec
program, and then that program would clean up the content of that
directory).
--
Eli Marmor
[EMAIL PROTECTED]
Netmask (El-Mar) Internet Technologies Ltd.
__________________________________________________________
Tel.: +972-9-766-1020 8 Yad-Harutzim St.
Fax.: +972-9-766-1314 P.O.B. 7004
Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
