On 02/25/2011 09:54 AM, Křištof Želechovski wrote:
> == To reproduce: ==
> 
>   1. Find a file in /tmp owned by somebody else and not owned by you.  Say a.txt.
>   2. { ln a.txt b1.txt; } # you created b.txt based on a.txt

You created another name for a.txt; the permissions of the underlying
inode (whether you access it via the name a.txt or via the name b1.txt)
are the same; it is still owned by somebody else.

>   3. {  rm b1.txt; } # error: Operation not permitted.

This is a security feature.  /tmp is intentionally created with the
sticky deletion bit set, so that the only person that can remove a file
in that directory is the owner of the file.  Think of the consequences
if this were not the case: you create a temp file with mode 0600 (only
accessible to you), someone else spies the file name, removes your
inode, and creates a replacement file by the same name but a different
inode in its place but with mode 0666.  Then they can do whatever they
want with your temporary data, including reading what you thought was
private.  But in a sticky directory, the attack is thwarted - since they
don't own your file, they can't replace it with a different inode of the
same name but different permissions.

And yes, this means that creating hard links to someone else's file has
effectively created a file belonging to someone else, and not to you.
Just as you can't remove their original file, you can't remove the new
name you created for that file (but they can).

> Allowing irreversible operations is a bad thing,

But it is mandated by POSIX that a system that honors the sticky bit
must perform in this manner.  There's nothing we can do in coreutils to
change how link(2) behaves in the kernel, therefore, we can't make ln(1)
reject this call, even though the results are a bit surprising to a novice.

> == Workaround ==
> Never put anything into /tmp.  Use /tmp/kde-$LOGNAME (or whatever your directory is) instead.

That's a bit harsh.  Rather, the rule of thumb is don't create hard
links to anyone else's data in a sticky directory, because you won't own
those hard links.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org