--- Begin Message ---
|
Subject: |
ln to /tmp is irreversible |
|
Date: |
Fri, 25 Feb 2011 17:54:33 +0100 |
|
User-agent: |
KMail/1.13.6 (Linux/2.6.34.7-0.7-desktop; KDE/4.6.0; x86_64; ; ) |
== 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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#8117: ln to /tmp is irreversible |
|
Date: |
Sat, 9 Apr 2011 21:58:48 -0600 |
|
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
--- End Message ---