Date: Mon, 6 Nov 2006 17:10:17 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-hackers@FreeBSD.ORG, elessar@bsdforen.de Subject: Re: [patch] rm can have undesired side-effects Message-ID: <200611061610.kA6GAHrM092749@lurza.secnetix.de> In-Reply-To: <20061105052832.68400a56@loki.starkstrom.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611061610.kA6GAHrM092749>