[patch] rm can have undesired side-effects

[Oliver Fromme]

First of all, just for the record, I also vote for removing
-P from rm(1), for reasons already mentioned by others.

It was intended as a security feature, but such a security
feature must have a well defined and very clear behaviour,
and it must work correctly under all circumstances.  The -P
option cannot do that.  It's a good example of a security
feature that can easily be turned into a security risk.

Wiping and overwriting of unallocated disk blocks belongs
somewhere else, e.g. the FS driver (possibly as a mount
option), but defintiely not in rm(1).

Joerg Pernfuss wrote:
 > And I still have no idea why ln(1) allows links to files the user has
 > no access rights whatsoever, in a directory the owner of the file
 > has no access to in the first place.

Well, the permission bits of a file protect only the file's
contents, not the inode.  The inode is protected by the
permission bits of the directories that contain a reference
to it.  Creating a hardlink doesn't require accessing the
actual file contents, because it only creates another
reference to the inode, so you only need read permission for
the directory that contains the inode entry.

For exactly the same reason you can delete (unlink) other
people's files even if the permissions don't allow you to
access the file's contents.  You only need write permission
for the directory in order to remove the directory entry
(hardlink).

So, while the behaviour with creating hardlinks might be
considered a security flaw, at least it is consistent with
deleting them (and it's what should be expected, so it
doesn't violate POLA, in my opinion).

In the case of deleting a hardlink (i.e. unlink), the
security problem has been approached by the "sticky bit"
feature, which is usually set on /tmp (mdoe 1777), so you
cannot unlink other peoples files even though /tmp is
writable for everybody.

But for creating hardlinks, it's not that easy.  If you
don't want someone else to create hardlinks to your files,
make the directory mode 0700.  But that's not always
possible:  Sometimes you want others to be able to read
a directory and the files in it, but not be able to
hardlink them.  For that purpose it would be neccessary
to invent a new permission bit, analogous to the sticky
bit.  Global settings like FreeBSD's hardlink_check_*
sysctl are not a good solution.

By the way, a user _can_ prevent hardlinking his files by
setting the "immutable" flag (see chflags(1)) on the
files.  But it makes handling the files more diffcult for
the owner (he cannot edit them anymore etc.).

There are more pitfalls hidden in the jungle of permissions
and file flags.  For example, if Alice has set the "unlink"
flag on some of her files, and Brad tries to capture them
by hardlinking them into his directory, this will succeed,
_but_ then Brad will not be able to delete them:  unlink
will fail, even though Brad owns the directory and has
write access to it.  He cannot move them either -- but he
can move the directory they're in (within the same file
system).  In other words, Brad has shot his foot pretty
badly and will require Alice's help to get rid of the hard-
links:  The only solution is that Alice removes the unlink
flag on her files, and only then will Brad be able to
remove the hardlinks from his directory.  Pretty weird if
you ask me.  But consistent behaviour.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"I made up the term 'object-oriented', and I can tell you
I didn't have C++ in mind."
        -- Alan Kay, OOPSLA '97