bug#8117: ln to /tmp is irreversible

[Bob Proulx]

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