GNU bug report logs - #8117
ln to /tmp is irreversible

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8117 in the body.
You can then email your comments to 8117 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Křištof Želechovski <giecrilj <at> stegny.2a.pl>
To: bug-coreutils <at> gnu.org
Subject: ln to /tmp is irreversible
Date: Fri, 25 Feb 2011 17:54:33 +0100

== 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
  3. {  rm b1.txt; } # error: Operation not permitted.
  4. Go to step 2, replacing b1 by b2, and so on.
(  5. ??? )
(  6. Profit. )

== The conclusion ==
Allowing irreversible operations is a bad thing, and this is not a circumstance where an exception would be appropriate.  The tool ln should not allow the operator to create an entry he cannot delete.

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

IMHO,
Chris

Message #8 received at 8117 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Křištof Želechovski <giecrilj <at> stegny.2a.pl>
Cc: 8117 <at> debbugs.gnu.org
Subject: Re: bug#8117: ln to /tmp is irreversible
Date: Fri, 25 Feb 2011 13:24:06 -0700

[Message part 1 (text/plain, inline)]

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 <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 8117 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Křištof Želechovski <giecrilj <at> stegny.2a.pl>
Cc: 8117 <at> debbugs.gnu.org
Subject: Re: bug#8117: ln to /tmp is irreversible
Date: Fri, 25 Feb 2011 14:01:40 -0700

tags 8117 + notabug
thanks

Křištof Želechovski wrote:
>   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
>   3. {  rm b1.txt; } # error: Operation not permitted.

Yes this is true.  But this doesn't have anything to do with either
'ln' or 'rm' but is instead a behavior associated with Unix
filesystems and specifically the behavior of the sticky-bit on
directories.  It is an operating system policy.  Therefore I am
tagging this as not a bug in the bug tracking system.

>   4. Go to step 2, replacing b1 by b2, and so on.
> (  5. ??? )
> (  6. Profit. )

You are concerned that an authorized local user can fill up any open
writable sticky-bit directory with files that they cannot remove
themselves.  But if you have a locally authorized user that is causing
trouble then you already know this user and can take action against
them.  This is not a remote attack vulnerability.

In other words, this is very similar to someone who lives in the house
and who leaves the kitchen in your house dirty.  If someone who lives
in your house doesn't clean up the pots and pans after they use them
then this will impact other members who also live in the house.  But
they live in the house and you know them.  Remove their kitchen
privileges if they do not behave.

> Allowing irreversible operations is a bad thing, and this is not a
> circumstance where an exception would be appropriate.  The tool ln
> should not allow the operator to create an entry he cannot delete.

Whether that is true or not doesn't really matter to coreutils since
it is the filesystem in the kernel that enforces those permissions.
It isn't something that ln or rm or other program has any ability to
do anything about it.

Note that there are different filesystems other than the Unix
filesystem model.  People keep trying to improve the model with other
paradigms such as ACLs and so forth.  Perhaps one day the Unix
filesystem model will be replaced with something quite different.  But
for the past forty years it has been the current model.

Thank you for your report anyway.

Bob

Message #18 received at 8117-done <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Křištof Želechovski <giecrilj <at> stegny.2a.pl>
Cc: 8117-done <at> debbugs.gnu.org
Subject: Re: bug#8117: ln to /tmp is irreversible
Date: Sat, 9 Apr 2011 21:58:48 -0600

Bob Proulx wrote:
> Křištof Želechovski wrote:
> >   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
> >   3. {  rm b1.txt; } # error: Operation not permitted.
> 
> Yes this is true.  But this doesn't have anything to do with either
> 'ln' or 'rm' but is instead a behavior associated with Unix
> filesystems and specifically the behavior of the sticky-bit on
> directories.  It is an operating system policy.  Therefore I am
> tagging this as not a bug in the bug tracking system.

There wasn't any further discussion, it is an operating system
filesystem behavior, and so I am closing this bug in the bug tracking
system for coreutils.

Bob

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.