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

[R0b0t1]

On Fri, Jul 28, 2017 at 12:02 PM, Reuti <address@hidden> wrote:
> Hi,
>
>> Am 28.07.2017 um 18:28 schrieb R0b0t1 <address@hidden>:
>>
>> 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
<address@hidden> 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.