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
