bug#27864: [request] safety to prevent `rm -rf ~`

[Bernhard Voelker]

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