GNU bug report logs - #27864
[request] safety to prevent `rm -rf ~`

Previous Next

Package: coreutils;

Reported by: R0b0t1 <r030t1 <at> gmail.com>

Date: Fri, 28 Jul 2017 16:55:01 UTC

Severity: wishlist

Tags: wontfix

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#27864; Package coreutils. (Fri, 28 Jul 2017 16:55:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to R0b0t1 <r030t1 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Fri, 28 Jul 2017 16:55:02 GMT) Full text and rfc822 format available.

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

From: R0b0t1 <r030t1 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: [request] safety to prevent `rm -rf ~`
Date: Fri, 28 Jul 2017 11:28:12 -0500
I recently had a script create a file named "~" when I passed it a
value for an installation directory. Without thinking the next command
I typed was the one in the title. Luckily this was not my main
computer and was a virtual machine.

It does not seem likely a user will ever intentionally type `rm -rf
~`. Deletion of home directories usually takes place as another user.
Most of the arguments used for the addition of --no-preserve-roots and
the `rm -rf /` safeties also seem to apply in this case, as just as
one could erroneously type `rm -rf / directory` one could type `rm -rf
~ /directory` (or even the impressive yet redundant `rm -rf ~ /
directory`).

R0b0t1.




Information forwarded to bug-coreutils <at> gnu.org:
bug#27864; Package coreutils. (Fri, 28 Jul 2017 17:03:02 GMT) Full text and rfc822 format available.

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

From: Reuti <reuti <at> staff.uni-marburg.de>
To: R0b0t1 <r030t1 <at> gmail.com>
Cc: 27864 <at> debbugs.gnu.org
Subject: Re: bug#27864: [request] safety to prevent `rm -rf ~`
Date: Fri, 28 Jul 2017 19:02:50 +0200
Hi,

> Am 28.07.2017 um 18:28 schrieb R0b0t1 <r030t1 <at> gmail.com>:
> 
> I recently had a script create a file named "~" when I passed it a
> value for an installation directory.

Most likely as the input was taken literally and not expanded.


> Without thinking the next command
> I typed was the one in the title. Luckily this was not my main
> computer and was a virtual machine.
> 
> It does not seem likely a user will ever intentionally type `rm -rf
> ~`. Deletion of home directories usually takes place as another user.
> Most of the arguments used for the addition of --no-preserve-roots and
> the `rm -rf /` safeties also seem to apply in this case, as just as
> one could erroneously type `rm -rf / directory` one could type `rm -rf
> ~ /directory` (or even the impressive yet redundant `rm -rf ~ /
> directory`).

Doesn't the Bash expand ~ with /home/your_user or whatever was set as home directory? The `rm` will never see the plain ~, unless one writes ./~ or alike.

-- Reuti





Information forwarded to bug-coreutils <at> gnu.org:
bug#27864; Package coreutils. (Fri, 28 Jul 2017 17:08:01 GMT) Full text and rfc822 format available.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: R0b0t1 <r030t1 <at> gmail.com>, 27864 <at> debbugs.gnu.org
Subject: Re: bug#27864: [request] safety to prevent `rm -rf ~`
Date: Fri, 28 Jul 2017 19:07:15 +0200
On 07/28/2017 06:28 PM, R0b0t1 wrote:
> I recently had a script create a file named "~" when I passed it a
> value for an installation directory. Without thinking the next command
> I typed was the one in the title. Luckily this was not my main
> computer and was a virtual machine.
> 
> It does not seem likely a user will ever intentionally type `rm -rf
> ~`. Deletion of home directories usually takes place as another user.
> Most of the arguments used for the addition of --no-preserve-roots and
> the `rm -rf /` safeties also seem to apply in this case, as just as
> one could erroneously type `rm -rf / directory` one could type `rm -rf
> ~ /directory` (or even the impressive yet redundant `rm -rf ~ /
> directory`).

rm(1) does not see the tilde "~", but the shell expands it before
invoking the tool:

  $ echo rm ~
  rm /home/berny

I would think it's awkward if rm(1) would try the opposite to find
out whether an argument matches $HOME.  And in some situations, the
HOME environment variable might not be accurate as it could easily
be tweaked:

  $ env HOME=/some/other sh -c 'echo $HOME'
  /some/other

I don't see a secure way to rely on the HOME variable just for
protecting a certain directory.  Finally, we'd have to fstat()
in order to compare the resolved file name of it.

So while the mere wish seems tempting, I don't see an easy and
reliable way to implement it.

Have a nice day,
Berny






Information forwarded to bug-coreutils <at> gnu.org:
bug#27864; Package coreutils. (Sat, 29 Jul 2017 01:35:02 GMT) Full text and rfc822 format available.

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

From: R0b0t1 <r030t1 <at> gmail.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 27864 <at> debbugs.gnu.org
Subject: Re: bug#27864: [request] safety to prevent `rm -rf ~`
Date: Fri, 28 Jul 2017 20:26:26 -0500
On Fri, Jul 28, 2017 at 12:02 PM, Reuti <reuti <at> staff.uni-marburg.de> wrote:
> Hi,
>
>> Am 28.07.2017 um 18:28 schrieb R0b0t1 <r030t1 <at> gmail.com>:
>>
>> I recently had a script create a file named "~" when I passed it a
>> value for an installation directory.
>
> Most likely as the input was taken literally and not expanded.
>

Right. Just explaining how it happened, and most other times I have
had files be created with strange names (e.g. starting with -) it has
been the result of a command interpreting something literally. It is
hard but not impossible to create "bad" file names like this, and
creating such files is almost always not what the user intends in my
experience.

>
>> Without thinking the next command
>> I typed was the one in the title. Luckily this was not my main
>> computer and was a virtual machine.
>>
>> It does not seem likely a user will ever intentionally type `rm -rf
>> ~`. Deletion of home directories usually takes place as another user.
>> Most of the arguments used for the addition of --no-preserve-roots and
>> the `rm -rf /` safeties also seem to apply in this case, as just as
>> one could erroneously type `rm -rf / directory` one could type `rm -rf
>> ~ /directory` (or even the impressive yet redundant `rm -rf ~ /
>> directory`).
>
> Doesn't the Bash expand ~ with /home/your_user or whatever was set as home directory? The `rm` will never see the plain ~, unless one writes ./~ or alike.
>

It does, but that API is available for use in other programs via wordexp(3).
Additionally the value obtained by expanding ~ is available in $HOME.


On Fri, Jul 28, 2017 at 12:07 PM, Bernhard Voelker
<mail <at> bernhard-voelker.de> wrote:
> On 07/28/2017 06:28 PM, R0b0t1 wrote:
>> I recently had a script create a file named "~" when I passed it a
>> value for an installation directory. Without thinking the next command
>> I typed was the one in the title. Luckily this was not my main
>> computer and was a virtual machine.
>>
>> It does not seem likely a user will ever intentionally type `rm -rf
>> ~`. Deletion of home directories usually takes place as another user.
>> Most of the arguments used for the addition of --no-preserve-roots and
>> the `rm -rf /` safeties also seem to apply in this case, as just as
>> one could erroneously type `rm -rf / directory` one could type `rm -rf
>> ~ /directory` (or even the impressive yet redundant `rm -rf ~ /
>> directory`).
>
> rm(1) does not see the tilde "~", but the shell expands it before
> invoking the tool:
>
>   $ echo rm ~
>   rm /home/berny
>
> I would think it's awkward if rm(1) would try the opposite to find
> out whether an argument matches $HOME.  And in some situations, the
> HOME environment variable might not be accurate as it could easily
> be tweaked:
>
>   $ env HOME=/some/other sh -c 'echo $HOME'
>   /some/other
>

I agree the only way to solve the problem (compare arguments against
$HOME) is not a nice one, but it is the only one that makes sense. I
propose it because it is fairly limited in scope and a lot of the
discussion surrounding `rm -rf /` seems applicable to ensuring that ~
is not passed as a bare argument to rm(1).

> I don't see a secure way to rely on the HOME variable just for
> protecting a certain directory.  Finally, we'd have to fstat()
> in order to compare the resolved file name of it.
>

I'm not sure why you would suggest relying on $HOME might be a
security issue. The semantics of ~ are that it expands to $HOME, and
$HOME can only ever contain text should it not also contain a valid
directory path (unless something is very broken, and not just in or
for rm(1)). Most programs obtain behavior targetting the home
directory by using $HOME, so that it would be set to something else
would be very strange indeed, and regardless, if it was, that is what
~ now refers to.

I can't see how it would be necessary to use fstat(2). The argument
list to rm(1) can be checked for the contents of $HOME.

> So while the mere wish seems tempting, I don't see an easy and
> reliable way to implement it.
>

It should be pointed out that despite various ways to get around the
safety on `rm -rf /` (such as `rm -rf /*`) it was still implemented.
If no one wants to implement it that is fine; I may never find the
time myself to do it and can't expect more of anyone else, but the
suggestion seems to agree with the logic used previously on the list.

R0b0t1.




Information forwarded to bug-coreutils <at> gnu.org:
bug#27864; Package coreutils. (Sat, 29 Jul 2017 07:15:02 GMT) Full text and rfc822 format available.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: R0b0t1 <r030t1 <at> gmail.com>, Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 27864 <at> debbugs.gnu.org
Subject: Re: bug#27864: [request] safety to prevent `rm -rf ~`
Date: Sat, 29 Jul 2017 00:13:53 -0700
R0b0t1 wrote:
> I'm not sure why you would suggest relying on $HOME might be a
> security issue.

For example, if I'm running a script that executes "rm -fr /special/dir/secret" 
and want to fool the script into not removing its secret file, I could simply 
run the script in an environment where HOME=/special/dir/secret.




Information forwarded to bug-coreutils <at> gnu.org:
bug#27864; Package coreutils. (Sat, 29 Jul 2017 16:06:01 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: R0b0t1 <r030t1 <at> gmail.com>, 27864 <at> debbugs.gnu.org
Subject: Re: bug#27864: [request] safety to prevent `rm -rf ~`
Date: Sat, 29 Jul 2017 09:05:05 -0700
On 28/07/17 09:28, R0b0t1 wrote:
> I recently had a script create a file named "~" when I passed it a
> value for an installation directory. Without thinking the next command
> I typed was the one in the title. Luckily this was not my main
> computer and was a virtual machine.
> 
> It does not seem likely a user will ever intentionally type `rm -rf
> ~`. Deletion of home directories usually takes place as another user.
> Most of the arguments used for the addition of --no-preserve-roots and
> the `rm -rf /` safeties also seem to apply in this case, as just as
> one could erroneously type `rm -rf / directory` one could type `rm -rf
> ~ /directory` (or even the impressive yet redundant `rm -rf ~ /
> directory`).

This was one of the reasons that upstream ls defaults to quoting
problematic file names like this. With that you can always
copy and paste the name ('~' in this case), for subsequent use.
Even if not copy/pasting '~' would give a visual indication
that the quoting was needed. If your distro disables that feature,
you can enable it in your ls alias using --quoting='shell-escape'

cheers,
Pádraig





Information forwarded to bug-coreutils <at> gnu.org:
bug#27864; Package coreutils. (Mon, 29 Oct 2018 03:36:01 GMT) Full text and rfc822 format available.

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 27864 <at> debbugs.gnu.org
Subject: Re: bug#27864: [request] safety to prevent `rm -rf ~`
Date: Sun, 28 Oct 2018 21:35:09 -0600
severity 27864 wishlist
tags 27864 wontfix
close 27864
stop

(triaging old bugs)

On 2017-07-29 10:05 a.m., Pádraig Brady wrote:
> On 28/07/17 09:28, R0b0t1 wrote:
>> I recently had a script create a file named "~" when I passed it a
>> value for an installation directory. Without thinking the next command
>> I typed was the one in the title. Luckily this was not my main
>> computer and was a virtual machine.
>>

On 2017-07-28 11:07 a.m., Bernhard Voelker wrote:
>
> rm(1) does not see the tilde "~", but the shell expands it before
> invoking the tool:


> This was one of the reasons that upstream ls defaults to quoting
> problematic file names like this. With that you can always
> copy and paste the name ('~' in this case), for subsequent use.
> Even if not copy/pasting '~' would give a visual indication
> that the quoting was needed. If your distro disables that feature,
> you can enable it in your ls alias using --quoting='shell-escape'
> 

Given the above, and no further comments in a year,
I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf




Severity set to 'wishlist' from 'normal' Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Mon, 29 Oct 2018 03:36:02 GMT) Full text and rfc822 format available.

Added tag(s) wontfix. Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Mon, 29 Oct 2018 03:36:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 27864 <at> debbugs.gnu.org and R0b0t1 <r030t1 <at> gmail.com> Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Mon, 29 Oct 2018 03:36:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 26 Nov 2018 12:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 124 days ago.

Previous Next


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