[patch] rm can have undesired side-effects

Joerg Pernfuss elessar at bsdforen.de
Sun Nov 5 04:28:45 UTC 2006


On Sat, 4 Nov 2006 18:22:39 -0800 (PST)
Matthew Dillon <dillon at apollo.backplane.com> wrote:

> :    I agree.  I will make this change in DragonFly right now, in
> : fact. The -P option really needs to be consistent across
> : environments and my take on the original design was so users could
> : alias rm to rm -P in their .cshrc files.  Clearly it cannot destroy
> : the contents of the file in the presence of hard links when used in
> : that context.
> :
> :					-Matt
> 
>     Followup note here.  OpenBSD's /bin/rm source is doing something
>     unexpected... it isn't unlink()ing the file if it has > 1
> hardlinks and -P is used.  That is its current behavior.

Yes, delphij@ and I stumbled upon that as well. It isn't really
reflected in the man page and the initial OpenBSD commit log
	"Attempt to do something reasonable when overwrite mode is
	 combined with hard links, and document it. In consultation
	 with dynamo and approved by millert."
isn't that conclusive either. With the objection that was raised around
here, maybe it was done intentionally.

>     I'm not sure I agree with this.  It makes -P unusable as a .cshrc
> alias. I would have expected it to still unlink the file.

Yes, this behaviour breaks `rm -r' when rm is aliased to rm -P, which
limits the usefulness of the -P flags significantly imho. But it
makes sure one does not miss the warning. Just hope for good error
handling in the script.

>     In anycase, for now I am going to sync DragonFly's rm with
> OpenBSD anyhow, even though I'm scratching my head a bit.  This may
> be just as broken as before, just in a different (and safer) way.

So far the easiest mayhem one could cause (aside from safekeeping
someone elses file) I could think of is in a quota environment. If
Mallory links all of Alice's files, then Alice's quota will fill up,
because she probably can't delete her files anymore.
Yet as they preserve owner and access mode, they will count towards
Alice's limit I would assume. Quotas are set on a per-filesystem, not
per-path basis (according to quotactl(2), not tested).

If Mallory set up the directory in which the files got linked just as
bad as Alice set up her ~/, then Alice can either delete the malicious
links (write access to the directory), link them back (execute access
to the directory) or watch them sit there (read access to the directory).
In the first case, everything is good. In the second one, she can at
least dd(1) the file and destroy the data, although the quota will fill.
In the third, Alice can try to somehow magically write directly to that
inode - no idea. But the quota will fill up.


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. And what happens when I link the
0600 file state_secret.doc that is owned by someone else, into a
directory I own and set SUIDDIR? Will that then be my file and the
original owner will be denied access on his link to the file?
(yes, kernel support required, i know. but it would be fun.)

I am not convinced anymore that rm is the real culprit.

	Joerg
-- 
| /"\   ASCII ribbon   |  GnuPG Key ID | e86d b753 3deb e749 6c3a |
| \ / campaign against |    0xbbcaad24 | 5706 1f7d 6cfd bbca ad24 |
|  X    HTML in email  |        .the next sentence is true.       |
| / \     and news     |     .the previous sentence was a lie.    |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20061105/a855f68c/signature.pgp


More information about the freebsd-hackers mailing list