GNU bug report logs - #34700
rm refuses to remove files owned by the user, even in force mode

Previous Next

Full log

Message #14 received at 34700 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Nicolas Mailhot <nicolas.mailhot <at> laposte.net>, 34700 <at> debbugs.gnu.org
Subject: Re: bug#34700: rm refuses to remove files owned by the user, even in
 force mode
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.