Re: [coreutils] A more forgiving rm.

[Eric Blake]

On 08/24/2010 11:10 AM, Dan Hipschman wrote:
> Hi,
>
> I forked off my own copy of rm to play with and have added the
> following functionality.
>
> 1. If the --warnings (-w) option is given, read the file
> ~/.rmfd/warn.list if it exists.  The format is one absolute path per
> line.  Before any files are removed, see if any file in the list would
> be removed by the invocation, and if so, warn and prompt the user for
> each file found whether it is OK to continue.  Note that this
> overrides --force.  If the user declines, exit with status
> EXIT_FAILURE.  If the user allows it, continue with the usual
> semantics.  Note that rm also checks as it is removing files, so if it
> finds a file that is in the list that wasn't warned about during the
> initial check, it will still prompt, but the "abort the entire
> operation" semantics can't be carried out.

Right now, I'm roughly 70-30 against adding a black-listing option, 
although you may want to get feedback from more than just me.

If we do add it, I don't like the name --warnings.  I'd rather name it 
something like --black-list=FILE, and make the user explicitly pass in 
the file name containing the blacklist, rather than assuming a default 
location (under the assumption that anyone using this on a regular basis 
will set up a shell alias or wrapper script to supply their preferred 
location, be it ~/.rmfd/warn.list or somewhere else, rather than always 
typing the option name).  We don't have any other precedence of a 
hard-coded configuration locations in coreutils, and we DO have 
precedence of dircolors taking an arbitrary location for determining a 
user's preferred ls coloring, which has in turn been easily modified by 
distros into shell startup scripts which can then supply a 
distro-specific file location such as ~/.dircolors, all without having 
to hard-code that into coreutils itself.

Also, I would rather not burning a short-option letter -w until we know 
whether such a feature will be widely-used enough to warrant that.

Doing a two pass traversal (once to see if anything blacklisted might be 
encountered, and again when doing the actual deletion) is inherently 
racy; I can see your intent of making the entire operation abortable if 
any one black-listed file is among a pile of files rather than getting 
half-way through the operation before encountering the first problem 
file, but that is entirely new behavior compared to the standardized 
approach of a single pass.  There is no way to avoid races with such a 
new option, and I fear that the corner cases caused by such races may 
cause more surprises than what black-listing intends to solve on the 
surface.

Rather than requiring every line be an absolute file name (inherently 
broken, given that filenames can contain newlines), I'd rather see 
something that lets you intersperse comments, as well as use a 
combination of globs and escape sequences for literal representation of 
*, \n, #, etc.  In fact, you could even use extended globs such as 
'/dir/**' to black-list both the directory and all its contents (which 
would then obviate your hack in point 3 designed to protect someone from 
doing 'rm dir/*' without first explicitly blacklisting all of dir's 
contents).  Additionally, I don't see why you require absolute pathnames 
(what if I want to black-list the relative name 'Makefile', regardless 
of the directory I am in?).  But all of this will result in yet more 
complexity for a new option.

Finally, this only helps if you actually use 'rm' and the new option. 
But it doesn't blacklist anything from any other means of deletion, such 
as a script that calls 'rm', or manual use of 'mv', or even deletion 
done by gui management tools.  In other words, it is a false sense of 
security, and too easily bypassed.  I think there are much more secure 
ways of protecting important files, such as ACLs, SELinux labeling, and 
immutable attributes, which, by virtue of being kernel-enforced, will 
apply to ALL programs and not just rm.  So why bloat rm with a 
half-baked feature, when a full-baked feature is already available from 
the kernel?

> 4. Add color to the warning prompt when stderr is a tty.

This sounds like an independent change.  In general, adding the option 
to colorize the prompt and/or verbose output of rm, mv, cp, and so on, 
should be proposed as an independent patch series, rather than tying it 
to an (as-yet) controversial new option.

> I would appreciate feedback on the concept or the code.  I am still
> interested in hearing if this could be considered as an extension to
> GNU rm on the grounds that the extra code is not substantial
> (Coreutils' rm stripped is 47K on my system and rmfd's rm is 50K) and
> the performance hit and POSIX noncompliance is entirely opt-in.

I've checked the FSF copyright records; while you still have assignment 
on file, your employers' disclaimer appears to have expired as of June 
2008.  So as not to taint myself until this issue is resolved, I have 
not looked at your patches for now.

Now, if the rest of my email has been a bit discouraging, let me end on 
a more positive note.  Thanks for taking the time to contribute, even if 
in the end your patches are not used upstream.  Because this is open 
source, you are more than welcome to run your custom rm in your 
environment, and get the benefits that you see in your patch, even if 
you have not managed to convince others of the same.  I wish more people 
would approach feature requests with patches rather than proposals.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org