[nycbug-talk] Safety Expansion for FreeBSD rm(1)

[Miles Nordin]

>>>>> "jc" == Jesse Callaway <bonsaime at gmail.com> writes:

    jc> It won't break any scripts at all. It just makes
    jc> the system more useable and in a friendly way.

probably not, but goofy little pet features like .rmrc ought to go in
your shell, not /bin/rm, along with all other weird customizations
that some people want and others find disgusting.  That's what shells
are _for_---we already have a place to put features like this about
which we feel so ambivalent, without upsetting anyone.  'rm' is an
extremely simple program that needs to behave in an extremely simple
and unsurprising way.

What if ~/ is automounted, and the automounter can't reach your home
NFS server?  You did 'ls ~' and it froze, so you somehow got a new
shell started and are being careful not to touch ~, using only the
simplest commands like cp, mv, ls, rm, but rm went hunting in its
homedir for ~/.rmrc and froze again.  Eventually enough tools absorb
this attitude, and you're left with the Windows-like idea, ``oh, well,
the system is just dependent on the home directory.  Nothing will work
without it, even in single-user mode.  Fix that first, then rescue
your system.''

What if some malicious user creates a named pipe named ${CWD}/.rm?
(oops, we forgot.  ok, we'll check for named pipes.  and so on and so
on.).  Or maybe creating a /dev/.rm makes the openpty() call insecure,
or /tmp/.rm can facilitate some race condition.  What if it breaks a
script because the script is trying to delete a ``protected'' file
that really should be deleted, like the rm -rf of an entire subtree
implied by an mv across filesystems?  What if <something I haven't
thought of>.

Never mind that the only people asking for it are careless idiots who
incorrectly believe that something silly like this could possibly
offer them any meaningful protection from their own clumsiness and
lack of backup planning (I mean, honestly, what special, important
names would you put in these .rm files littered all over the place
like .DS_Store and .Thumbs?  Almost all my files are ``important''.
The stated example of bin/ is a really bad one because system binaries
are among the easiest things to replace if you accidentally delete
them, so why worry?  Instead, should I put every mail folder, every
five-year-old journal entry? but never mind that:)  The feature
actually is harmful.  It's only slightly and very hypothetically
harmful, but balanced against the expected simpleness of this tool
it's too much.

    sk> it seems like it is breaking some unwritten unix law

the law is please don't ``pull an AIX'' by ripping out traditional
Unix stuff and replacing it with new stuff that is in certain
surprising ways worse than the old stuff just because some obscure,
quirky person has convinced himself the way he invented is ``better.''

When I login to some used-up whore of a box where vi has been silently
replaced with vim, and I can't paste anything because of auto-indent,
and I get mandatory syntax highlighting that turns text to unreadable
blue-on-black, and there's a row-column counter in the lower-right to
keep my 9600bps console saturated, and I'm getting VM/CMS style error
messages like '<beep>E048123: Affect cruton REVSV!', and 'u....'
doesn't work as it should, and when I complain the guy says, ``oh well
you can customize all that stuff away, and that's what's so great
about vim'' I want to slap someone around with a rotting trout yelling
THATS...YOUR...PROBLEM...NOT...MINE.  vi is vi.  vim is vim.  Use vim,
love vim, and maybe it is ``great,'' but don't call it vi or think
providing it excuses you from delivering vi if you want to call your
platform Unix.  It's like delivering bash and thinking this means you
don't have to provide a Bourne shell.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20071002/9f416f71/attachment.bin>