[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27864: [request] safety to prevent `rm -rf ~`
From: |
Bernhard Voelker |
Subject: |
bug#27864: [request] safety to prevent `rm -rf ~` |
Date: |
Fri, 28 Jul 2017 19:07:15 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 |
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