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
