| |||||||||||||
Shortening the rope (around RH's neck)Shortening the rope (around RH's neck)Posted Apr 3, 2009 19:27 UTC (Fri) by madscientist (subscriber, #16861)Parent article: Shortening the rope All hail our Editor! Jon you are absolutely correct: before anyone should complain about these other minor and obscure issues, Red Hat should be appropriately flogged for this horrific default alias (Fedora just inherited this from Red Hat proper, AFAICT). Anyone who sits down and thinks about it for a minute will realize that changing the behavior of a critical command like "rm" to increase the level of safety, using a method which is as transient and easily breakable as a shell alias, is a horrible idea. All you are doing is teaching people to assume and rely on the fact that "rm" will ask them before removing a file... so when they drop over to someone else's account, where this alias is not present, the potential for utter disaster is real and constant. If Red Hat felt the need to create a "safer" rm, they should have used a different name such as "alias rmi='rm -i'" or similar. Of course at this point they will argue that all their customers expect it so they can't change it. Sigh. This is how crap accretes.
(Log in to post comments)
Shortening the rope (around RH's neck) Posted Apr 3, 2009 20:18 UTC (Fri) by vblum (guest, #1151) [Link]
Odd ....
alias rm='rm -i'
has saved me a number of times, and there is always rm -f to undo it if need be ... so the _point_ is that -i is not a strong restriction, no?
Shortening the rope (around RH's neck) Posted Apr 3, 2009 21:07 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
But -f doesn't just undo it
it also causes rm to remove readonly things that it would have previously stopped on
So by accepting this bit of 'protection' against one particular failure mode you've increased your exposure to another.
(The preserve root thing seems like 100% win to me
)
Shortening the rope (around RH's neck) Posted Apr 6, 2009 11:18 UTC (Mon) by vblum (guest, #1151) [Link]
hm, yes, but I tend to actually think twice before I ever type "-f" ... because that is not routine ... anyway, just a personal thing.
Shortening the rope (around RH's neck) Posted Apr 3, 2009 21:31 UTC (Fri) by mgh (guest, #5696) [Link]
heh - this will do what you want "\rm"
However, I have become so accustomed to using this form that I then to do it by default and have accidently removed files I didn't mean to ....
alias rm="rm -i" ends up being worthless because it drives the average user mad. But alias mv="mv -i" has saved me a few times and the same with cp.
Shortening the rope (around RH's neck) Posted Apr 3, 2009 21:35 UTC (Fri) by madscientist (subscriber, #16861) [Link]
If you weren't used to "rm" always asking, you'd be more careful (personally I use alias rm='rm -f' and I'm always careful :-)). Maybe you'd use "rm -i" explicitly when you wanted to be asked.
Believe me it doesn't take more than one time of not having that alias around, for whatever reason, running "rm" with the expectation it will ask you before deleting anything, and destroying important work to realize what a bad idea this is.
Shortening the rope (around RH's neck) Posted Apr 5, 2009 19:09 UTC (Sun) by jengelh (subscriber, #33263) [Link]
If rm -f is considered too dangerous, and rm -i too noisy, then try something like
function rm()
and let cron evict it time and again.
Shortening the rope (around RH's neck) Posted Apr 6, 2009 11:28 UTC (Mon) by vblum (guest, #1151) [Link]
hm, no, not true for me ... I was perfectly accustomed to to normal rm for a long time, until I once deleted my home directory. Once is all it takes (mind you, that was one out of >= 10^5 rm's that I ever typed).
Anything that asks you before deleting will make you think, even if it's after typing "y" for the 15th time ("hm .... strange that I am still typing "y" although I was only going to delete two files ... hm ...")
As for the second point, of course I wouldn't think of figuring out what I actually wanted to delete after being asked by -i ... that completely defeats the purpose of a safety net (and maybe that is why many in the thread do not understand why rm -i is a good thing, because it can be used for the purpose of making a deliberate selection ...)
Shortening the rope (around RH's neck) Posted Apr 3, 2009 22:07 UTC (Fri) by fmarier (subscriber, #19894) [Link]
Personally, I welcome some of the new protections. IMO It's not about losing control, it's about preventing smart and competent sysadmins from costly accidents.
For example, there are cases where I can see no good reason to be able to delete a specific directory (e.g. /, /bin, etc.). In fact, having done that by accident at some point, I would have preferred safer defaults.
That's why I decided to write safe-rm (http://www.safe-rm.org.nz) to blacklist certain directories and files. It's aliased to rm on my machine but I can always use "/bin/rm" if I really wanted to delete my /usr/lib.
Shortening the rope (around RH's neck) Posted Apr 3, 2009 23:51 UTC (Fri) by nix (subscriber, #2304) [Link]
What does safe-rm do that 'chattr +i' doesn't?
Shortening the rope (around RH's neck) Posted Apr 4, 2009 7:17 UTC (Sat) by Cato (subscriber, #7643) [Link]
chattr +i would stop any changes at all to a file, including normal version upgrades of executables. Something like safe-rm is a bit more focused on preventing accidental deletions. However, "chattr +i / /usr" might be a good idea as it doesn't depend on someone using safe-rm etc.
Shortening the rope (around RH's neck) Posted Apr 5, 2009 1:58 UTC (Sun) by Simetrical (guest, #53439) [Link]
chattr +i on a directory will stop any files in the directory from being modified, from a quick test, but it won't stop subdirectories from being removed recursively by rm -r. So it's only really useful on files, but you don't want to make files in /bin unmodifiable -- they need to be be changed in system upgrades. So for the same reason you don't want to make /bin unmodifiable (it seems to prevent some modifications to files it contains, certainly at least removal and likely overwriting of all kinds).
Shortening the rope (around RH's neck) Posted Apr 5, 2009 11:56 UTC (Sun) by nix (subscriber, #2304) [Link]
Ew. I didn't realise that. That seems like an rm -r bug to me.
Shortening the rope (around RH's neck) Posted Apr 5, 2009 17:11 UTC (Sun) by JoeF (guest, #4486) [Link]
Why not mount /, /bin,... read-only?
Keep everything you need to write to, e.g., /tmp, /var, on separate filesystems. That's what I do, and it works nicely. Of course, you could still end up deleting your home directory...
Shortening the rope (around RH's neck) Posted Apr 7, 2009 13:44 UTC (Tue) by hmh (subscriber, #3838) [Link]
You need /etc to be RW, and you need that very early in the boot sequence, so it traditionally has to be inside /. That's the only thing that gets in the way of mounting / RO.
accidental deletion and read-only root filesystem Posted Apr 9, 2009 23:37 UTC (Thu) by giraffedata (subscriber, #1954) [Link] You do have to use a rather different filesystem layout than what comes with conventional Linux to have a read-only root filesystem. I've been doing it for years, though. Sometimes it's as easy as having symbolic links from the root filesystem to a read/write filesystem, but other times it's as hard as having to modify a program to eliminate a hardcoded file name.I also do daily automated backups. Deleting my home directory wouldn't be particularly severe for me.
Shortening the rope (around RH's neck) Posted Apr 17, 2009 11:34 UTC (Fri) by Ross (subscriber, #4065) [Link]
But rm isn't the only tool which can be misused. Do you have safe versions of tar, chmod, chown,
and mv for example? What about graphical file managers?
This seems much more like something you should be able to do through permissions rather than
Shortening the rope (around RH's neck) Posted Apr 4, 2009 15:21 UTC (Sat) by man_ls (subscriber, #15091) [Link] I agree with you completely; enabling all the "-i" aliases is one of the first things I do for every new Debian user. Even for root. It seems that the rough Linux pioneers who shaved with rusty knives and for whom "Linux from scratch" was unnecessarily bloated have a different taste for danger than us settlers.
Shortening the rope (around RH's neck) Posted Apr 3, 2009 22:53 UTC (Fri) by smoogen (subscriber, #97) [Link]
I believe the change was put in because of customer complaints back in the late 90's. And yes putting it in caused a calvacade of responses that Red Hat was the AOL of Linux.. or was that the Microsoft of Linux.. ranters couldn't decide which was worse and the flame war ended up with them tearing up each other over it.
In the end it was pointed out that is an alias which pretty much everyone of the ranters really didn't run into because well they had already made their own .bashrc as good hackers should. Those who had not.. well it was a good exercise on becoming a hacker in finding out how to ignore it.
Shortening the rope (around RH's neck) Posted Apr 10, 2009 18:47 UTC (Fri) by madscientist (subscriber, #16861) [Link] A lot of people are misunderstanding my comment, and thinking that I mean you should just use the default and never change it, and learn to live with the blood on the floor. That's not what I'm saying. What I mean is that it's irresponsible (at best) for Red Hat to ship their standard shell configuration, especially for root, where they override the default behavior of a critical application like rm to be something "safer".I've said above, but I'll repeat: what this does is encourage people who learn Linux/UNIX on Red Hat systems to assume that the default behavior of rm is to ask before deleting every file. I'm sure everyone here can see why this is bad! Those people go to someone elses system, or log in as a different account, or even write a shell script!, or whatever that doesn't happen to have that magical alias installed, and they run rm expecting to be asked about every file... and before they know it they've deleted an entire directory or worse. I have similar complaints about those of you who say you set up your user's accounts to contain this alias before they ever log in. You may think you're doing them a service, but in the long run it's more dangerous. I have no problem with creating a DIFFERENT alias, like "rmi", that aliases to "rm -i", and encouraging people to use that instead of "rm". And of course I have no problem with someone creating their OWN alias, in their own shell config file, to do whatever they want: hopefully they will be aware enough to be careful at that point. But it's wrong and dangerous to set aliases like this in the shell config of unsuspecting users.
Shortening the rope (around RH's neck) Posted Apr 24, 2009 18:40 UTC (Fri) by Max.Hyre (subscriber, #1054) [Link] All you are doing is teaching people to assume and rely on the fact that "rm" will ask them before removing a file... so when they drop over to someone else's account, where this alias is not present, the potential for utter disaster is real and constant.Would that that were the only danger. The assumption and reliance mean that when they ``rm -r *'' and are asked for confirmation, they'll type in `y' without thinking—it becomes no protection at all. True story: Ages ago (25 years?) I worked on Datapoint systems, early versions of microcomputers. At the time, the only non-volatile storage was floppy disks, so we formatted and rewrote them continually. Their format protection was of the form (sequence of answers real, questions forgotten, and so made up):
> format
My fingers were so used to this rigmarole that typing ``yyny'' was controlled by my hindbrain—absolutely no thought involved. If I'd made a mistake, I had no more chance of catching it than if I'd typed ``# rm -rf /''. Such mechanisms are a snare and a delusion. FWIW: When I'm setting up some potentially disastrous command, I always start the line with `#'. That way, if my finger accidentally hits the <CR> key, Bash will just say ``Ho, hum—another comment.'' When I've built up the command to my satisfaction, I remove the hash and send the command on its way.
|
|||||||||||||