Subject: bug#34700: rm refuses to remove files owned by the user, even in force mode

From: Eric Blake <[email-masked]>
Date: Fri, 1 Mar 2019 08:46:22 -0600

On 3/1/19 8:14 AM, Nicolas Mailhot wrote:
> Le vendredi 01 mars 2019 à 07:58 -0600, Eric Blake a écrit :
>>
>> The behavior of -f is specified by POSIX:
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html
>>
>> and is specified to suppress prompts and avoid diagnostics on missing
>> files, but NOT a means to force deletion via changing directory
>> permissions.  For that, you'd need a new option, because we can't
>> change
>> the long-specified meaning of -f without breaking scripts.
> 
> Well it seems people got spoiled by other OSes where read-only is not-
> really-read-only-when-you-own-the-file (IIRC vi also ignores permissions
> in force mode).
> 
> So could a really-force flag be added?

Remember, unlink() requires write permissions on the container
directory. If a directory is read-only, unlink() alone CANNOT remove a
file, no matter who owns it (and that is true for ALL operating
systems). Unlinking a read-only file from a writable directory is
different than attempting to unlink from a read-only directory.

If rm is taught a new option to temporarily chmod() a directory to be
writable, just to perform the unlink(), should it then chmod() the
directory back to its original state or leave it writable when complete?
 What do you do about races (now that you are asking for a sequence of 2
or 3 syscalls instead of one, you have to worry about interactions with
another process also trying to cause you TOCTTOU security bugs)?  And
since such an option would be new, where you have to wait for new-enough
rm to be available in your distro, vs. the fact that you can already now
portably do a two-step chmod before rm.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org