Re: Protection from the dreaded rm -fr /
--On 2004-10-2 11:19 AM +0300 Giorgos Keramidas [EMAIL PROTECTED] wrote: John Beck, who works for Sun, has posted an entry in his blog yesterday about rm -fr / protection, which I liked a lot: http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection The best protection from 'rm -rf /' is an ATT 3B4000 computer. I had the misfortune of dealing with one in the late '80s. After I convinced management that it was ... well ... a waste of time, we held a de-commissioning party. Somewhere around 2030 (hours) I took the liberty to do something I have wanted to do on a live production system for a long time: 1. login as root 2. rm -rf / We did this, in party mode, with a couple of bottles of champaign, streamers, and a bit of Frank Zappa and Cap't Beefheart in the background. By midnight, we were getting worried that last call at the pub would end before the machine. So, we left. And came back. And left again to come back with offsales, on account of said machine not only being deathly slow in life, but also in suicide. I think we gave up around 0530 and just pulled the AC from the box and went home. Or back to the bar. For a month. To get over the brain damage of the 3B4K. (We inflicted less upon ourselves :-) Of course, this was just a little while after All Of Usenet hit 5MB per day, so I don't expect anyone to get this anecdote correct on their MCSE exam :-) --lyndon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm -I patch (Re: Protection from the dreaded rm -fr /)
Here is the final commit I made to DFly. I cleaned up the confirmation message somewhat to make it more useful and correct the grammer. I'm not saying that this should or should not be done in FreeBSD, but I cannot think of any negatives and the -I option does allow for a far more sophisticated check then just '/' and a far less annoying confirmation then -i. http://www.dragonflybsd.org/cvsweb/src/bin/rm/rm.1.diff?r1=1.2r2=1.3f=u http://www.dragonflybsd.org/cvsweb/src/bin/rm/rm.c.diff?r1=1.3r2=1.4f=u http://www.dragonflybsd.org/cvsweb/src/etc/csh.cshrc.diff?r1=1.2r2=1.3f=u http://www.dragonflybsd.org/cvsweb/src/etc/profile.diff?r1=1.2r2=1.3f=u -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Wednesday 06 October 2004 02:31, Matthew Dillon wrote: The university I used to work for had something like it and it got 99% of the cases Yow. 78 messages and counting. Er, 79 now. I'll bet poor Giorgos wishes he never started this thread! Get ready. get set DIVE! A good friend of mine has, for at least the last two decades, used something along the lines of: if ( $?prompt ) then alias rm 'mv \!* $HOME/misc/trash' endif However, it seems that the correct solution is to create a new option, -I, which puts rm into 'idiot user mode' and has all the desired confirmation effects listed in this thread and none of the undesired effects such as -i returns. Then if anyone wants to use it they can just create an alias similar to the above for -I and poof, problem solved. It's fairly easy to detect '*' and ask for confirmation, and also easy to ask for a single confirmation on a directory (not ask again for any recursion). Then you guys can argue over whether the alias should appear in the system-wide default csh.cshrc and friends, rather then argue over the destruction of rm's basic nature. I will only point out that 'rm' is used fairly universally in scripts and there are obviously things other then '/' that you would want to ask confirmation for that just as obviously cannot be made default operation for rm. -Matt Matthew Dillon [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, 2 Oct 2004, Greg Black wrote: As for protecting against rm -rf / foo as a typo for rm -rf /foo, I don't mind if we offer protection against that; but I see no reason at all to protect root from rm -rf /. It's fair to say that somebody who types that means it, and it's fair to go as far as we can in satisfying it. I think you just nailed it on the head right here... if you say rm -rf / you probably mean it, but if you say rm -rf / foo you probably oopsed (pretty good bet, since rm / makes asking to rm foo redundant). How about checking if there is more than one argument, and if one of those arguments is /, fail. If there is only one argument, even if it is /, assume the user knows what he is doing and proceed normally. -- Chris Dillon - cdillon(at)wolves.k12.mo.us FreeBSD: The fastest, most open, and most stable OS on the planet - Available for IA32, IA64, AMD64, PC98, Alpha, and UltraSPARC architectures - PowerPC, ARM, MIPS, and S/390 under development - http://www.freebsd.org Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
As for protecting against rm -rf / foo as a typo for rm -rf /foo, I don't mind if we offer protection against that; but I see no reason at all to protect root from rm -rf /. It's fair to say that somebody who types that means it, and it's fair to go as far as we can in satisfying it. I think you just nailed it on the head right here... if you say rm -rf / you probably mean it, but if you say rm -rf / foo you probably oopsed (pretty good bet, since rm / makes asking to rm foo redundant). How about checking if there is more than one argument, and if one of those arguments is /, fail. If there is only one argument, even if it is /, assume the user knows what he is doing and proceed normally. Why not let -i override -f? Then the usual alias bit works fine for those who want it. For times when you really want the -f, you can type /bin/rm -rf. Or `which rm` -rf. Or put it in a shell script and call it rmf. There are a lot of ways to skin this properly without resorting to hacks making the tool smarter than the user. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-05 10:37, Chris Dillon [EMAIL PROTECTED] wrote: I think you just nailed it on the head right here... if you say rm -rf / you probably mean it, but if you say rm -rf / foo you probably oopsed (pretty good bet, since rm / makes asking to rm foo redundant). How about checking if there is more than one argument, and if one of those arguments is /, fail. If there is only one argument, even if it is /, assume the user knows what he is doing and proceed normally. I no longer have any interest in working towards any sort of change related to this thread. Please do not Cc: me when replying. Thanks, Giorgos ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-06 03:12, Giorgos Keramidas [EMAIL PROTECTED] wrote: On 2004-10-05 10:37, Chris Dillon [EMAIL PROTECTED] wrote: I no longer have any interest in working towards any sort of change related to this thread. Please do not Cc: me when replying. I'm not picking on Chris Dillon here. It's more like a request to trim my address from replies to this thread, from now on. Thanks to all who have discussed this with me. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
Yow. 78 messages and counting. Er, 79 now. I'll bet poor Giorgos wishes he never started this thread! Get ready. get set DIVE! A good friend of mine has, for at least the last two decades, used something along the lines of: if ( $?prompt ) then alias rm 'mv \!* $HOME/misc/trash' endif However, it seems that the correct solution is to create a new option, -I, which puts rm into 'idiot user mode' and has all the desired confirmation effects listed in this thread and none of the undesired effects such as -i returns. Then if anyone wants to use it they can just create an alias similar to the above for -I and poof, problem solved. It's fairly easy to detect '*' and ask for confirmation, and also easy to ask for a single confirmation on a directory (not ask again for any recursion). Then you guys can argue over whether the alias should appear in the system-wide default csh.cshrc and friends, rather then argue over the destruction of rm's basic nature. I will only point out that 'rm' is used fairly universally in scripts and there are obviously things other then '/' that you would want to ask confirmation for that just as obviously cannot be made default operation for rm. -Matt Matthew Dillon [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
rm -I patch (Re: Protection from the dreaded rm -fr /)
I think I'll commit something like this to DragonFly (you might
get patch errors w/ FreeBSD but this is the basic idea).
-Matt
Index: rm.1
===
RCS file: /cvs/src/bin/rm/rm.1,v
retrieving revision 1.2
diff -u -r1.2 rm.1
--- rm.117 Jun 2003 04:22:50 - 1.2
+++ rm.16 Oct 2004 01:34:12 -
@@ -81,6 +81,11 @@
option overrides any previous
.Fl f
options.
+.It Fl I
+Request confirmation once if more then three files are being removed or if a
+directory is being recursively removed. This is a less intrusive dumb-user
+option then
+.Fl i
.It Fl P
Overwrite regular files before deleting them.
Files are overwritten three times, first with the byte pattern 0xff,
Index: rm.c
===
RCS file: /cvs/src/bin/rm/rm.c,v
retrieving revision 1.3
diff -u -r1.3 rm.c
--- rm.c30 Aug 2004 19:27:21 - 1.3
+++ rm.c6 Oct 2004 01:52:46 -
@@ -51,9 +51,11 @@
#include unistd.h
int dflag, eval, fflag, iflag, Pflag, vflag, Wflag, stdin_ok;
+int rflag, Iflag;
uid_t uid;
intcheck(char *, char *, struct stat *);
+intcheck2(char **);
void checkdot(char **);
void rm_file(char **);
void rm_overwrite(char *, struct stat *);
@@ -70,7 +72,7 @@
int
main(int argc, char *argv[])
{
- int ch, rflag;
+ int ch;
char *p;
/*
@@ -94,7 +96,7 @@
}
Pflag = rflag = 0;
- while ((ch = getopt(argc, argv, dfiPRrvW)) != -1)
+ while ((ch = getopt(argc, argv, dfiIPRrvW)) != -1)
switch(ch) {
case 'd':
dflag = 1;
@@ -107,6 +109,9 @@
fflag = 0;
iflag = 1;
break;
+ case 'I':
+ Iflag = 1;
+ break;
case 'P':
Pflag = 1;
break;
@@ -138,6 +143,10 @@
if (*argv) {
stdin_ok = isatty(STDIN_FILENO);
+ if (Iflag) {
+ if (check2(argv) == 0)
+ exit (1);
+ }
if (rflag)
rm_tree(argv);
else
@@ -442,6 +451,47 @@
return (first == 'y' || first == 'Y');
}
+int
+check2(char **argv)
+{
+ struct stat st;
+ int first;
+ int ch;
+ int fcount = 0;
+ int dcount = 0;
+ int i;
+
+ for (i = 0; argv[i]; ++i) {
+ if (lstat(argv[i], st) == 0) {
+ if (S_ISDIR(st.st_mode))
+ ++dcount;
+ else
+ ++fcount;
+ }
+ }
+ first = 0;
+ while (first != 'n' first != 'N' first != 'y' first != 'Y') {
+ if (dcount fcount rflag) {
+ fprintf(stderr,
+ recursively remove %d dirs and %d files? ,
+ dcount, fcount);
+ } else if (dcount rflag) {
+ fprintf(stderr,
+ recursively remove %d dirs? , dcount);
+ } else if (dcount + fcount 3) {
+ fprintf(stderr, remove %d files? , dcount + fcount);
+ } else {
+ return(1);
+ }
+ fflush(stderr);
+
+ first = ch = getchar();
+ while (ch != '\n' ch != EOF)
+ ch = getchar();
+ }
+ return (first == 'y' || first == 'Y');
+}
+
#define ISDOT(a) ((a)[0] == '.' (!(a)[1] || ((a)[1] == '.' !(a)[2])))
void
checkdot(char **argv)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
Thomas David Rivers writes: If I'm remembering correctly - the historical way to do this is to alias the rm command to something that else that checks the arguments and complains appropriately (and then executes /bin/rm.) Typically with just a shell alias. That keeps you from accidently doing something. Yeah. $ alias rm=rm -i and you get the annoying confirm all deletes behaviour. Just thinking that putting extra smarts into a utility isn't the typical UNIXy way to do this. Let each tool do the one thing it does really well.. 'rm' removes; let it remove. Right. There are SO many special cases here that rm cannot possibly catch them all: # cd / ; rm -rf foo/ * ^ This space is a typo. I think, in the old UNIX Review magazine (what - almost 15+ years ago now?) There was a couple of examples of this. Many others as well. Windows' job is to prevent you from shooting yourself in the foot. With UNIX, the idea is to make damn sure that there is a hole in your foot with the greatest possible efficiency. (Paraphrased) I've typed rm -rf * in the wrong place. ONCE. I learned Unix-fu from that experience. Now, if I type rm anything, I wake up. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
Hi Giorgos!
On 02 Oct 04 at 10:51, Giorgos (Giorgos Keramidas) wrote:
Giorgos The reason I liked this idea is that root has zillions of other
Giorgos ways to destroy an entire system, but not many of them are likely
Giorgos to be the result of mistyping a single character as shown below:
Giorgos # rm -fr / home/someuser/*
I just wonder, if 'rm' is so fearful to you, why bother changing rm(1)?
Write a simple wrapper around, as many sysadmins do for their needs,
and use it instead of rm.
#!/usr/bin/perl -w
for (@ARGV) {die $_ is a boo-boo!\n if m/^\//}
exit system 'rm' , @ARGV;
--
Sincerely,
Dmitry Karasik
---
catpipe Systems ApS
*BSD solutions, consulting, development
www.catpipe.net
+45 7021 0050
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Mon, 4 Oct 2004, Dmitry Karasik wrote: I just wonder, if 'rm' is so fearful to you, why bother changing rm(1)? Write a simple wrapper around, as many sysadmins do for their needs, and use it instead of rm. Precisely. This is -hackers; why do we need to be protected from ourselves? You typed it, you suffer the consequences (and you'll think very carefully before hitting RETURN next time). Or don't you trust those to whom you have given root access? I can't believe we're having this conversation. -- Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-04 12:15, Dmitry Karasik [EMAIL PROTECTED] wrote:
On 02 Oct 04 at 10:51, Giorgos (Giorgos Keramidas) wrote:
Giorgos The reason I liked this idea is that root has zillions of other
Giorgos ways to destroy an entire system, but not many of them are likely
Giorgos to be the result of mistyping a single character as shown below:
Giorgos # rm -fr / home/someuser/*
I just wonder, if 'rm' is so fearful to you, why bother changing rm(1)?
Write a simple wrapper around, as many sysadmins do for their needs,
and use it instead of rm.
#!/usr/bin/perl -w
for (@ARGV) {die $_ is a boo-boo!\n if m/^\//}
exit system 'rm' , @ARGV;
I've lost interest in making any sort of changes to rm(1) after the first
dozen or so of messages like this one.
Has nobody else seen the logical fallacy of keeping rm(1) unchanged in order
to avoid changes that might not be there in the next system and suggesting a
locally customized hack like a shell/perl/whatever wrapper as a better
alternative? The shell wrapper will not be there in the next system either.
Introducing local incompatibilities and hacks like a perl script wrapper of
rm(1) is highly unportable. Simply switching between two different machines
will bite you in more dangerous ways than the current version of rm(1) that is
part of the system, once you start depending on the local hack you have in one
of the machines. Why this is deemed better than something that is part of the
source (tunable or not), is far beyond me.
Having said that, I'm not going to post about this topic in -hackers anymore
(or any other list, for that matter). The arguments against the change have
not been very true, coherent or satisfactory, but the general sentiment seems
to be that people want rm(1) unchanged. Unchanged it will be, then.
Thanks to all who posted on the thread. I didn't intend to start a flamewar
of some sort, but I did. I apologize for wasting everyone's time bandwidth.
- Giorgos
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Mon, Oct 04, 2004 at 01:49:51PM +0300, Giorgos Keramidas wrote: I've lost interest in making any sort of changes to rm(1) after the first dozen or so of messages like this one. Don't get too disappointed: http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/rm/rm.c.diff?r1=1.48r2=1.49 changes by [EMAIL PROTECTED] --Stijn -- Nostalgia ain't what it used to be. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Mon, Oct 04, 2004 at 08:27:45PM +1000, Dave Horsfall wrote: On Mon, 4 Oct 2004, Dmitry Karasik wrote: I just wonder, if 'rm' is so fearful to you, why bother changing rm(1)? Write a simple wrapper around, as many sysadmins do for their needs, and use it instead of rm. Precisely. This is -hackers; why do we need to be protected from ourselves? All the world is not -hackers. Ceri -- I hear thought presenting the problem. -- dadadodo -c 1 Mail/trhodes pgpIxzzXKO4D7.pgp Description: PGP signature
Re: Protection from the dreaded rm -fr /
Ceri Davies wrote: On Mon, Oct 04, 2004 at 08:27:45PM +1000, Dave Horsfall wrote: On Mon, 4 Oct 2004, Dmitry Karasik wrote: I just wonder, if 'rm' is so fearful to you, why bother changing rm(1)? Write a simple wrapper around, as many sysadmins do for their needs, and use it instead of rm. Precisely. This is -hackers; why do we need to be protected from ourselves? All the world is not -hackers. I have more than enough bikeshedwood now to get past the winter, could we stop this now please ? -- -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Monday 04 October 2004 09:08, Mark Murray wrote: Yeah. $ alias rm=rm -i and you get the annoying confirm all deletes behaviour. Remember that -r over-rides -i, so the warning does not appear: bash-2.05b$ mkdir blah bash-2.05b$ rm -irf blah bash-2.05b$ mkdir blah bash-2.05b$ rm -if blah rm: blah: is a directory bash-2.05b$ rm -ir blah remove blah? y bash-2.05b$ -- Cheers, Chris Howells -- [EMAIL PROTECTED], [EMAIL PROTECTED] Web: http://chrishowells.co.uk, PGP ID: 0x33795A2C KDE/Qt/C++/PHP Developer: http://www.kde.org pgpl3heTMft2V.pgp Description: PGP signature
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Giorgos Keramidas [EMAIL PROTECTED] writes: : On 2004-10-02 19:29, M. Warner Losh [EMAIL PROTECTED] wrote: : In message: [EMAIL PROTECTED] : Tillman Hodgson [EMAIL PROTECTED] writes: : : It'll never work, though, that's the thing. At some point it'll rm : : something it itself needs and error out. There isn't a way to use `rm : : -rf /` that /doesn't/ result in foot-shooting. : : No. You are wrong. if you rm -rf in a chroot, then it won't result : in foot shooting, necessarily, like it would outside a chroot. : : Since a chroot can always be rm -fr deleted from outside the chroot, : this isn't really a great problem, is it? You miss the point. You said it was always a foot-shooting move. I gave you a concrete example of where it wasn't a foot-shooting move (or even when you could use newfs instead). You reply with a workaround (which may be a valid way to deal, maybe not). My point still stands: it isn't always a foot-shooting move. This is the only convincing argument against the proposed change that I've heard yet. I was assuming that doing this would cause something (e.g. the shell) to blow up even within a chroot, but I guess that isn't true, since all of the needed inodes will still be referenced until the shell exits. I guess to make this feature justifiable under the ``you are definitely trying to shoot yourself in the foot'' criterion, it would need to be disabled in chrooted environments. AFAIK, there isn't a simple way to detect chrootedness from userland, so this is starting to sound like a much larger kludge than I originally thought... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
The problem can be solved by installing only slow disks and mounting filesystems in sync mode. As it takes so long to delete files in this environment, you have plenty of time to hit ctrl-c when you realise what you've done. ;) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Saturday 02 October 2004 09:51, Giorgos Keramidas wrote: Yes, so? Does it mean we should always point guns at our feet and hope that we don't accidentally pull the trigger because some unlucky event made us jump a bit up? It just seems pointless to prevent yourself shooting yourself with a pistol, when you can still shoot yourself with the rifle, machine gun... -- Cheers, Chris Howells -- [EMAIL PROTECTED], [EMAIL PROTECTED] Web: http://chrishowells.co.uk, PGP ID: 0x33795A2C KDE/Qt/C++/PHP Developer: http://www.kde.org pgp6I5oj1lXA0.pgp Description: PGP signature
Re: Protection from the dreaded rm -fr /
In [EMAIL PROTECTED], Giorgos Keramidas [EMAIL PROTECTED] typed: John Beck, who works for Sun, has posted an entry in his blog yesterday about rm -fr / protection, which I liked a lot: http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: Aw, but watching how systems fail when you do rm -rf / after you take them out of service is so entertaining. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
In [EMAIL PROTECTED], Ryan Sommers [EMAIL PROTECTED] typed: Edwin Groothuis wrote: On Sat, Oct 02, 2004 at 11:19:28AM +0300, Giorgos Keramidas wrote: I'm not so much worried about 'rm -rf /', but I'm more worried about rm -rf * in my home directory. It happened once because I was too happy switching directories before realising what I was doing in the wrong directory. If you use tcsh for your shell add: set rmstar to your .cshrc file. Then anytime you use '*' as an argument to rm it will ask you if you are sure you want to do that. zsh does this by default as well. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
In message: [EMAIL PROTECTED] Tillman Hodgson [EMAIL PROTECTED] writes: : On Sat, Oct 02, 2004 at 07:29:51PM -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Tillman Hodgson [EMAIL PROTECTED] writes: : : It'll never work, though, that's the thing. At some point it'll rm : : something it itself needs and error out. There isn't a way to use `rm : : -rf /` that /doesn't/ result in foot-shooting. : : No. You are wrong. if you rm -rf in a chroot, then it won't result : in foot shooting, necessarily, like it would outside a chroot. : : If you're chrooted, where is the rm binary and associated libraries? : They're in the chroot, in a branch off hte virtual / tree root. rm doesn't have to live in the chroot. Consider chroot /some/path/to/a/chroot rm -rf / in this case, everything under the /some/path/to/a/chroot would be removed. However, the rm that's running is outside of the chroot. This is typically how chroot commands are run, often from shell scripts. : `rm -rf /`, even in chroot, won't delete everything that the command : looks like it will. It can delete just about everything, see above. : At the very least the final unlink, that of / : itself, will likely result in undefined behaviour. Purhaps, but that's not rm's job: to protect you from something that might be undefined. unlink(2) is undefined for remote file systems as well. Maybe it will work, maybe it won't. : Where do the dev's : go if there's no / to root them in? etc etc. Doesn't matter. Irrelevant. The chroot might not have a devfs mounted in it, or any dev nodes at all. /dev isn't required for most operations. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
The rm -fr / is not dreaded. What is dreaded is running that command and other equally dangerous rm variants by mistake. Usually, the mistake comes from not paying attention to what you are typing or where you are in the directory hierarchy (for example, rm -rf * is probably much more likely than rm -rf / and can be equally destructive if run in the wrong directory). One practical solution to this problem is to train people not to use the rm command, in favor of some other command--say, del--with no recursive, force, or other options. For example, !#/bin/sh rm -- $* would probably be close to what is needed by a /usr/bin/del command. For most users, there would be no rm command, just as there is currently no dd or mknod command. If someone does the research to discover rm(1), and if they make the decision to use it by default instead of del, then there's nothing anyone can do to protect them. But if del is advertised as the safer version of rm, and it is recommended to users that it be the default, with rm reserved for special, extreme cases, then I think you will get the desired result, with zero breakage of existing scripts conventions. Greg Shenaut ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sun, 3 Oct 2004, M. Warner Losh wrote: [snip] MWL rm doesn't have to live in the chroot. Consider MWLchroot /some/path/to/a/chroot rm -rf / MWL in this case, everything under the /some/path/to/a/chroot would be MWL removed. However, the rm that's running is outside of the chroot. Not to be too nit-picking, but this is not true, as far as I can understand chroot(8) and chroot(2) ;-) However, since rm is usually statically linked and/or all needed code segments are referenced during rm work are loaded/referenced, this operation finishes successfully (just checked on 4-STABLE and -CURRENT). ... and no, I do *NOT* want to participate in this bikesched color discussion! ;-P Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
A simple and pragmatic solution is to use alias in what ever shell you are using e.g. alias rm to rm -i. There used to be a simple delete command or script that basically moved all files into a .deleted directory insted of actually deleting the files - From a practical point of view it does the trick because it forces anybody to use the escaped version if they really want to delete the files. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
M. Warner Losh [EMAIL PROTECTED] writes: rm doesn't have to live in the chroot. Consider chroot /some/path/to/a/chroot rm -rf / in this case, everything under the /some/path/to/a/chroot would be removed. However, the rm that's running is outside of the chroot. Wrong, and I'd be interested to hear how you think chroot(8) would pull that off if it were the case. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
# [EMAIL PROTECTED] / 2004-10-03 02:02:26 +0300: On 2004-10-02 17:22, Garance A Drosihn [EMAIL PROTECTED] wrote: At 8:57 PM +0300 10/2/04, Giorgos Keramidas wrote: On 2004-10-02 21:23, Lee Harr [EMAIL PROTECTED] wrote: How about: chflags sunlnk / ? Setting sunlink on / will only protect the / directory, not its descendants, so you don't gain much. We could add a new flag srunlnk, or maybe even srm-r. The rm command will always have to stat() the file it is given (just to see if it is a directory), so it could check to see if this flag is turned on. If it is turned on, then 'rm' could refuse to honor any '-rf' request on that directory. [...] Hmmm. This sounds much better indeed :-) have rm -r[f] behave just like find $@ -flags +sunlnk -prune -o -delete (I hope this is correct; if not: if the file has sunlnk among its chflags, skip it and its descendants) this is something I would, if not like, at least tolerate. specialcasing / stinks. it reminds me of all the RHEL machines I deal with at work that have alias rm rm -i, and I can only thank my luck this hasn't costed me an arm; ls | while read f; do rm -i $f; done is very dangerous, at least in bash. I have once deleted parts of my ~ with rm -fr *, but rm -fr / never happened to me, prolly because of my strong dependence on the shell completion. (I hope I'm not too drunk.) -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : M. Warner Losh [EMAIL PROTECTED] writes: : rm doesn't have to live in the chroot. Consider : chroot /some/path/to/a/chroot rm -rf / : in this case, everything under the /some/path/to/a/chroot would be : removed. However, the rm that's running is outside of the chroot. : : Wrong, and I'd be interested to hear how you think chroot(8) would : pull that off if it were the case. I was confused. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Protection from the dreaded rm -fr /
John Beck, who works for Sun, has posted an entry in his blog yesterday
about rm -fr / protection, which I liked a lot:
http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection
His idea was remarkably simple, so I went ahead and wrote this patch for
rm(1) of FreeBSD:
%%%
Index: rm.c
===
RCS file: /home/ncvs/src/bin/rm/rm.c,v
retrieving revision 1.47
diff -u -r1.47 rm.c
--- rm.c6 Apr 2004 20:06:50 - 1.47
+++ rm.c2 Oct 2004 08:06:21 -
@@ -157,6 +157,7 @@
void
rm_tree(char **argv)
{
+ char **argv_tmp;
FTS *fts;
FTSENT *p;
int needstat;
@@ -164,6 +165,17 @@
int rval;
/*
+* If one of the members of argv[] is the root directory abort the
+* entire operation.
+*/
+ argv_tmp = argv;
+ while (*argv_tmp != NULL) {
+ if (strcmp(*argv_tmp, /) == 0)
+ errx(1, rm of / is not allowed);
+ argv_tmp++;
+ }
+
+ /*
* Remove a file hierarchy. If forcing removal (-f), or interactive
* (-i) or can't ask anyway (stdin_ok), don't stat the file.
*/
%%%
To test it, I used a minimal chroot with /bin, /lib and /libexec copied
over from my real / partition:
# mkdir -p /tmp/chroot/bin ; cp -Rp /lib /libexec /tmp/chroot
# cp /bin/sh /bin/ls /tmp/chroot/bin
# cp /a/freebsd/src/bin/rm/rm /tmp/chroot/bin
# env PS1='chroot# ' chroot /tmp/chroot /bin/sh
chroot# rm -fr /
rm: recursive rm of / is not allowed
chroot# exit
#
It seems to work nicely here. I'm not sure if the overhead of
traversing argv[] twice is a bug price to pay for the protection this
adds, but if a lot of people like it I'll commit it when I get the
approval of src-committers :-)
- Giorgos
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004 at 11:19:28AM +0300, Giorgos Keramidas wrote: John Beck, who works for Sun, has posted an entry in his blog yesterday about rm -fr / protection, which I liked a lot: http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: I'm not so much worried about 'rm -rf /', but I'm more worried about rm -rf * in my home directory. It happened once because I was too happy switching directories before realising what I was doing in the wrong directory. Also, refusing to do it is not the ideal way to go, I think that if you have two -f's specified it would do it anyway. Just my two cents of course. Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://weblog.barnet.com.au/edwin/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, 2 Oct 2004, Giorgos Keramidas wrote: Date: Sat, 2 Oct 2004 11:19:28 +0300 From: Giorgos Keramidas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Protection from the dreaded rm -fr / John Beck, who works for Sun, has posted an entry in his blog yesterday about rm -fr / protection, which I liked a lot: http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: This does only help for the obvious case of '/' but not for the './' and '../' or '../../' ... accidents. Furthermore does it prevent root from doing `rm -rf /` which is a pretty legal operation for root since he knows what he is doing. This is UNIX, not Windows. Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-02 11:19, Giorgos Keramidas [EMAIL PROTECTED] wrote:
John Beck, who works for Sun, has posted an entry in his blog yesterday
about rm -fr / protection, which I liked a lot:
http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection
Here's a simpler diff, which I wrote after I looked a bit in the
while-loop I had and realized it was really an obfuscated for-loop:
%%%
Index: rm.c
===
RCS file: /home/ncvs/src/bin/rm/rm.c,v
retrieving revision 1.47
diff -u -r1.47 rm.c
--- rm.c6 Apr 2004 20:06:50 - 1.47
+++ rm.c2 Oct 2004 08:28:36 -
@@ -157,6 +157,7 @@
void
rm_tree(char **argv)
{
+ char **argv_tmp;
FTS *fts;
FTSENT *p;
int needstat;
@@ -164,6 +165,14 @@
int rval;
/*
+* If one of the members of argv[] is the root directory abort the
+* entire operation.
+*/
+ for (argv_tmp = argv; *argv_tmp != NULL; argv_tmp++)
+ if (strcmp(*argv_tmp, /) == 0)
+ errx(1, recursive rm of / is not allowed);
+
+ /*
* Remove a file hierarchy. If forcing removal (-f), or interactive
* (-i) or can't ask anyway (stdin_ok), don't stat the file.
*/
%%%
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-02 10:34, Michael Reifenberger [EMAIL PROTECTED] wrote: On Sat, 2 Oct 2004, Giorgos Keramidas wrote: Date: Sat, 2 Oct 2004 11:19:28 +0300 From: Giorgos Keramidas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Protection from the dreaded rm -fr / John Beck, who works for Sun, has posted an entry in his blog yesterday about rm -fr / protection, which I liked a lot: http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: This does only help for the obvious case of '/' but not for the './' and '../' or '../../' ... accidents. Hmm, indeed. This can be fixed, but it might take a little thinking over about ways to implement it without adding too much overhead to the way rm(1) works now. Furthermore does it prevent root from doing `rm -rf /` which is a pretty legal operation for root since he knows what he is doing. This is UNIX, not Windows. Yes, so? Does it mean we should always point guns at our feet and hope that we don't accidentally pull the trigger because some unlucky event made us jump a bit up? The reason I liked this idea is that root has zillions of other ways to destroy an entire system, but not many of them are likely to be the result of mistyping a single character as shown below: # rm -fr / home/someuser/* A single extra space can really wreak havoc in this case. If the real intention of the superuser is to delete everything, he can repartition his disk, he can dd if=/dev/zero of=/dev/ad0, he can do many things. Adding protection that prevents foot-shooting is not something without precedent to FreeBSD either: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/boot0cfg/boot0cfg.c.diff?r1=1.13r2=1.14 Having said that, if most people do like the change but there are others who don't, I can always make it work as before with a double -f option. - Giorgos ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
Edwin Groothuis wrote: On Sat, Oct 02, 2004 at 11:19:28AM +0300, Giorgos Keramidas wrote: John Beck, who works for Sun, has posted an entry in his blog yesterday about rm -fr / protection, which I liked a lot: http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: I'm not so much worried about 'rm -rf /', but I'm more worried about rm -rf * in my home directory. It happened once because I was too happy switching directories before realising what I was doing in the wrong directory. Also, refusing to do it is not the ideal way to go, I think that if you have two -f's specified it would do it anyway. Just my two cents of course. Edwin If you use tcsh for your shell add: set rmstar to your .cshrc file. Then anytime you use '*' as an argument to rm it will ask you if you are sure you want to do that. As for adding this kind of oops-proofing. I'm not sure I like the idea of completely removing the ability to use / as an argument. How about prompting and needing 'yes' as input? -- Ryan Sommers [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-02 18:33, Edwin Groothuis [EMAIL PROTECTED] wrote: On Sat, Oct 02, 2004 at 11:19:28AM +0300, Giorgos Keramidas wrote: John Beck, who works for Sun, has posted an entry in his blog yesterday about rm -fr / protection, which I liked a lot: http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: I'm not so much worried about 'rm -rf /', but I'm more worried about rm -rf * in my home directory. It happened once because I was too happy switching directories before realising what I was doing in the wrong directory. I can't do anything about that, I'm afraid. Also, refusing to do it is not the ideal way to go, I think that if you have two -f's specified it would do it anyway. Just my two cents of course. My intuition tells me that there is practically no case where root would really like to rm -fr the root partition. There are other ways to clean up a disk that are much faster and less prone to accidents. But I can make it behave as it does now with a double -f option. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-02 11:51, Giorgos Keramidas [EMAIL PROTECTED] wrote:
On 2004-10-02 10:34, Michael Reifenberger [EMAIL PROTECTED] wrote:
This does only help for the obvious case of '/' but not for the
'./' and '../' or '../../' ... accidents.
Hmm, indeed. This can be fixed, but it might take a little thinking
over about ways to implement it without adding too much overhead to the
way rm(1) works now.
One way to do that is to use realpath(3), but I have to ask more
knowledgeable people about the comment immediately below my change:
%%%
Index: rm.c
===
RCS file: /home/ncvs/src/bin/rm/rm.c,v
retrieving revision 1.47
diff -u -r1.47 rm.c
--- rm.c6 Apr 2004 20:06:50 - 1.47
+++ rm.c2 Oct 2004 09:00:41 -
@@ -157,6 +157,8 @@
void
rm_tree(char **argv)
{
+ char *rpath;
+ char **argv_tmp;
FTS *fts;
FTSENT *p;
int needstat;
@@ -164,6 +166,20 @@
int rval;
/*
+* If one of the members of argv[] is the root directory abort the
+* entire operation.
+*/
+ rpath = malloc(PATH_MAX * sizeof(char));
+ if (rpath == NULL)
+ err(1, malloc);
+ for (argv_tmp = argv; *argv_tmp != NULL; argv_tmp++) {
+ if (realpath(*argv_tmp, rpath) == NULL)
+ err(1, %s, *argv_tmp);
+ if (strcmp(rpath, /) == 0)
+ errx(1, recursive rm of / is not allowed);
+ }
+
+ /*
* Remove a file hierarchy. If forcing removal (-f), or interactive
* (-i) or can't ask anyway (stdin_ok), don't stat the file.
*/
%%%
I'm a bit worried about the don't stat the file comment below. The
realpath(3) library function *does* stat the file when trying to find
its real pathname ;-/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
[ Sorry to be so negative ... ]
At very least you should consider to error out silently as POSIX requires -f
to be silent. Other than that you should really look into the standards and
what they way about rm and friends.
I am not a fan of providing seat belts like this. People concerned about this,
can alias rm 'rm -i' etc. etc. Others have commented like this ...
If you still have to make this change, make it tuneable with a environment
variable (and make it default to off).
On Saturday 02 October 2004 10:19, Giorgos Keramidas wrote:
John Beck, who works for Sun, has posted an entry in his blog yesterday
about rm -fr / protection, which I liked a lot:
http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection
His idea was remarkably simple, so I went ahead and wrote this patch for
rm(1) of FreeBSD:
%%%
Index: rm.c
===
RCS file: /home/ncvs/src/bin/rm/rm.c,v
retrieving revision 1.47
diff -u -r1.47 rm.c
--- rm.c 6 Apr 2004 20:06:50 - 1.47
+++ rm.c 2 Oct 2004 08:06:21 -
@@ -157,6 +157,7 @@
void
rm_tree(char **argv)
{
+ char **argv_tmp;
FTS *fts;
FTSENT *p;
int needstat;
@@ -164,6 +165,17 @@
int rval;
/*
+ * If one of the members of argv[] is the root directory abort the
+ * entire operation.
+ */
+ argv_tmp = argv;
+ while (*argv_tmp != NULL) {
+ if (strcmp(*argv_tmp, /) == 0)
+ errx(1, rm of / is not allowed);
+ argv_tmp++;
+ }
+
+ /*
* Remove a file hierarchy. If forcing removal (-f), or interactive
* (-i) or can't ask anyway (stdin_ok), don't stat the file.
*/
%%%
To test it, I used a minimal chroot with /bin, /lib and /libexec copied
over from my real / partition:
# mkdir -p /tmp/chroot/bin ; cp -Rp /lib /libexec /tmp/chroot
# cp /bin/sh /bin/ls /tmp/chroot/bin
# cp /a/freebsd/src/bin/rm/rm /tmp/chroot/bin
# env PS1='chroot# ' chroot /tmp/chroot /bin/sh
chroot# rm -fr /
rm: recursive rm of / is not allowed
chroot# exit
#
It seems to work nicely here. I'm not sure if the overhead of
traversing argv[] twice is a bug price to pay for the protection this
adds, but if a lot of people like it I'll commit it when I get the
approval of src-committers :-)
- Giorgos
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
/\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
pgpl6TfsLjQdC.pgp
Description: PGP signature
Re: Protection from the dreaded rm -fr /
On 2004-10-02 03:52, Ryan Sommers [EMAIL PROTECTED] wrote:
On Sat, Oct 02, 2004 at 11:19:28AM +0300, Giorgos Keramidas wrote:
about rm -fr / protection, which I liked a lot:
http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection
His idea was remarkably simple, so I went ahead and wrote this patch
for
rm(1) of FreeBSD:
As for adding this kind of oops-proofing. I'm not sure I like the idea
of completely removing the ability to use / as an argument. How about
prompting and needing 'yes' as input?
This might break things because the user hasn't specified -i and will
suddenly get a prompt. Unexpected prompts might never get an answer.
I liked what Max Laier proposed though, about making this tunable and
defaulting to off. See below for the behavior of what I've come up with:
On 2004-10-02 11:23, Max Laier [EMAIL PROTECTED] wrote:
[ Sorry to be so negative ... ]
At very least you should consider to error out silently as POSIX
requires -f to be silent. Other than that you should really look
into the standards and what they way about rm and friends.
Agreed. Thanks for the feedback. Positive replies are not the only
sort that are worth a lot :-)
How does the following look instead of forcing stuff to the user?
1. Silently erroring out:
chroot# export RM_PROTECT_ROOT=1
chroot# /bin/rm -fr /
chroot# echo $?
1
chroot# /bin/rm -fr .././
chroot# echo $?
1
2. Warning with an error message because RM_PROTECT_ROOT is set:
chroot# export RM_PROTECT_ROOT=1
chroot# /bin/rm -r /
rm: recursive rm of / not allowed
chroot# /bin/rm -r .././
rm: recursive rm of / not allowed
3. The current behavior as a default when RM_PROTECT_ROOT is unset:
chroot# unset RM_PROTECT_ROOT
chroot# /bin/rm -r /
override rwxr-xr-x 0/0 for /bin/rm? ^Cchroot#
chroot#
chroot#
chroot# /bin/rm -fr /
rm: /libexec/ld-elf.so.1: Operation not permitted
rm: /libexec: Directory not empty
rm: /lib/libc.so.5: Operation not permitted
rm: /lib/libcrypt.so.2: Operation not permitted
rm: /lib: Directory not empty
rm: /: Is a directory
chroot# ls -l
ls: not found
chroot# echo *
lib libexec
chroot# cd lib
chroot# echo *
libc.so.5 libcrypt.so.2
chroot# exit
Here's the updated diff:
%%%
Index: rm.c
===
RCS file: /home/ncvs/src/bin/rm/rm.c,v
retrieving revision 1.47
diff -u -r1.47 rm.c
--- rm.c6 Apr 2004 20:06:50 - 1.47
+++ rm.c2 Oct 2004 10:06:59 -
@@ -57,7 +57,7 @@
#include sysexits.h
#include unistd.h
-int dflag, eval, fflag, iflag, Pflag, vflag, Wflag, stdin_ok;
+int dflag, eval, fflag, iflag, Pflag, vflag, Wflag, stdin_ok, protect_root;
uid_t uid;
intcheck(char *, char *, struct stat *);
@@ -100,6 +100,10 @@
exit(eval);
}
+ protect_root = 0;
+ if (getenv(RM_PROTECT_ROOT) != NULL)
+ protect_root = 1;
+
Pflag = rflag = 0;
while ((ch = getopt(argc, argv, dfiPRrvW)) != -1)
switch(ch) {
@@ -157,6 +161,8 @@
void
rm_tree(char **argv)
{
+ static char *rpath = NULL;
+ char **argv_tmp;
FTS *fts;
FTSENT *p;
int needstat;
@@ -164,6 +170,25 @@
int rval;
/*
+* If enabled in the environment with RM_PROTECT_ROOT disable the
+* ability to recursively remove the root directory.
+*/
+ if (protect_root) {
+ if (rpath == NULL
+ (rpath = malloc(PATH_MAX * sizeof(char))) == NULL)
+ err(1, malloc);
+ for (argv_tmp = argv; *argv_tmp != NULL; argv_tmp++) {
+ if (realpath(*argv_tmp, rpath) == NULL
+ strcmp(rpath, /) != 0)
+ continue;
+ if (fflag != 0)
+ exit (1);
+ else
+ errx(1, recursive rm of / not allowed);
+ }
+ }
+
+ /*
* Remove a file hierarchy. If forcing removal (-f), or interactive
* (-i) or can't ask anyway (stdin_ok), don't stat the file.
*/
%%%
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-02, Giorgos Keramidas wrote: I liked what Max Laier proposed though, about making this tunable and defaulting to off. See below for the behavior of what I've come up with: On 2004-10-02 11:23, Max Laier [EMAIL PROTECTED] wrote: [ Sorry to be so negative ... ] At very least you should consider to error out silently as POSIX requires -f to be silent. Other than that you should really look into the standards and what they way about rm and friends. Agreed. Thanks for the feedback. Positive replies are not the only sort that are worth a lot :-) Interesting -- if POSIX requires -f to be silent, we have quite a bit of work to do, as our rm is not silent in several cases of failure. And, while checking this, it wold be good to see what the standards say about exit values -- some errors are silent and return 0; others are noisy and return 1; there may be other possibilities, but I haven't checked exhaustively. As for protecting against rm -rf / foo as a typo for rm -rf /foo, I don't mind if we offer protection against that; but I see no reason at all to protect root from rm -rf /. It's fair to say that somebody who types that means it, and it's fair to go as far as we can in satisfying it. In any case, the new behaviour should only kick in if some environment variable is set and should not require doubled -f options. We all know how rm works and it's not broken. Greg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004 at 11:23:52AM +0200, Max Laier wrote: [ Sorry to be so negative ... ] At very least you should consider to error out silently as POSIX requires -f to be silent. Other than that you should really look into the standards and what they way about rm and friends. Are you sure? From the RATIONALE section of http://www.opengroup.org/onlinepubs/009695399/utilities/rm.html: It is less clear that error messages regarding files that cannot be unlinked (removed) should be suppressed. Although this is historical practice, this volume of IEEE Std 1003.1-2001 does not permit the -f option to suppress such messages. I am not a fan of providing seat belts like this. People concerned about this, can alias rm 'rm -i' etc. etc. Others have commented like this ... If you still have to make this change, make it tuneable with a environment variable (and make it default to off). I'd prefer that too. Ceri -- It is not tinfoil, it is my new skin. I am a robot. pgpFbCRBi9tq8.pgp Description: PGP signature
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004 at 11:51:43AM +0300, Giorgos Keramidas wrote: Adding protection that prevents foot-shooting is not something without precedent to FreeBSD either: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/boot0cfg/boot0cfg.c.diff?r1=1.13r2=1.14 Is that the correct reference? Ceri -- It is not tinfoil, it is my new skin. I am a robot. pgpl5oKaiPcHb.pgp Description: PGP signature
Re: Protection from the dreaded rm -fr /
On Saturday 02 October 2004 13:22, Ceri Davies wrote: On Sat, Oct 02, 2004 at 11:23:52AM +0200, Max Laier wrote: [ Sorry to be so negative ... ] At very least you should consider to error out silently as POSIX requires -f to be silent. Other than that you should really look into the standards and what they way about rm and friends. Are you sure? From the RATIONALE section of http://www.opengroup.org/onlinepubs/009695399/utilities/rm.html: It is less clear that error messages regarding files that cannot be unlinked (removed) should be suppressed. Although this is historical practice, this volume of IEEE Std 1003.1-2001 does not permit the -f option to suppress such messages. Misread - I stand corrected. I am not a fan of providing seat belts like this. People concerned about this, can alias rm 'rm -i' etc. etc. Others have commented like this ... If you still have to make this change, make it tuneable with a environment variable (and make it default to off). I'd prefer that too. Ceri -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpjABLpwRosR.pgp Description: PGP signature
Re: Protection from the dreaded rm -fr /
On Sat, 2004-Oct-02 11:51:43 +0300, Giorgos Keramidas wrote: The reason I liked this idea is that root has zillions of other ways to destroy an entire system, but not many of them are likely to be the result of mistyping a single character as shown below: # rm -fr / home/someuser/* I've had a customer write a cronjob that did almost exactly this. He managed to 'test' it on all the (redundant) production systems as well as the test model. We were only called in when he found that there were some unexpected console messages and the systems wouldn't boot when he pressed the reset button. Luckily it managed to kill itself before it destroyed all the evidence (since the culprit initially denied doing anything). Based on that, I'm definitely in favour of some anti-foot-shooting measures. I don't think it should fail quietly: If I ask the computer to do something (stupid or not), it should either do it or tell me that it hasn't done it. Failing to do what I ask and not telling me means that I can't trust the computer - I have to double-check that the files I wanted to delete have actually gone away. -- Peter Jeremy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-02 at 10:19:28 Giorgos Keramidas wrote: His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: Of course, your work is commendable, but isn't is much simpler to just not type commands like that? I mean, rm -rf /etc or rm -rf /bin are just as bad, but do you really want to be checking for all possible `bad' deletions? That way, we'll start to look like some software from Redmond... :) pgpzhYWqSGeM6.pgp Description: PGP signature
Re: Protection from the dreaded rm -fr /
On 2004.10.02 16:48:46 +0200, Dimitry Andric wrote: On 2004-10-02 at 10:19:28 Giorgos Keramidas wrote: His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: Of course, your work is commendable, but isn't is much simpler to just not type commands like that? I mean, rm -rf /etc or rm -rf /bin are just as bad, but do you really want to be checking for all possible `bad' deletions? That way, we'll start to look like some software from Redmond... :) As keramida has noted this particular case is more likely to be made by mistake than many others, e.g. by doing rm -rf / foo/bar where rm -rf /foo/bar/ was meant. Therefor I really think keramidas _optional_ foot-shooting feature is a nice thing. I know I will enable it on my systems if it's committed, and probably keep it as a local patch if not. -- Simon L. Nielsen FreeBSD Bikeshed Team pgpLItYADoz5L.pgp Description: PGP signature
Re: Protection from the dreaded rm -fr /
On Sat, 2 Oct 2004, Max Laier wrote: At very least you should consider to error out silently as POSIX requires -f to be silent. Other than that you should really look into the standards and what they way about rm and friends. Personally, I would want it to throw an error for the exit, but I do not know the standard. I am not a fan of providing seat belts like this. People concerned about this, can alias rm 'rm -i' etc. etc. Others have commented like this ... Seat belts that prevent a destructive action that may be desired only .001% (or much less) of the time do not bother me especially when the action is from a common tool. If the tool was rarely used (i.e., fdisk), or the action was desired much more often, then I could see a complaint about it. I already have that alias; -f overrides -i. It would drive me crazy for it to not override -i. Solaris does not allow -f to override -i and will ask for everything you want to delete recursively. I had to always type '/bin/rm -rf dir' to go around this. Highly annoying. If you still have to make this change, make it tuneable with a environment variable (and make it default to off). Why not default on? root will not run 'rm -rf /' on purpose very often. Once will be enough. :) Also, when and why would someone want to do this? Sean --- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
This is UNIX, not Windows. Agreed -- besides, it's only a matter of time before this and fourteen other -f related flags are incorporated into the gnu rm. Use it if you've got a problem with simple tools that do what you ask them to. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004 at 10:43:49PM +1000, Peter Jeremy wrote: I've had a customer write a cronjob that did almost exactly this. He managed to 'test' it on all the (redundant) production systems as well as the test model. We were only called in when he found that there were some unexpected console messages and the systems wouldn't boot when he pressed the reset button. Luckily it managed to kill itself before it destroyed all the evidence (since the culprit initially denied doing anything). Based on that, I'm definitely in favour of some anti-foot-shooting measures. [...] FWIW, I'm not in favor of adding ad-hoc features to handle edge-cases. (feature because this is actually introducing a bug :-) I picked this email to which to respond, because I can share my own stupidity. Case much like the one described above, but my cronjob included something like: cd /path/to/directory/with/temporary/files rm -fr * Only another admin removed `/path/to/directory/with/temporary/files'... so the `cd' failed and left the current directory as `/'. For some reason the system crashed :-) ... and then crashed again a few days after restoring from backup... doh! Will the next step be to prevent `rm -fr *' iff the current working directory is '/' ? Please explain your answer. :-) Cheers, -- Jacques A Vidrine / NTT/Verio [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004 at 10:42:16AM -0500, Sean Farley wrote: Why not default on? root will not run 'rm -rf /' on purpose very often. Once will be enough. :) Also, when and why would someone want to do this? Exactly. Who would expect `rm -rf /` to actually succeed? It's not only dangerous, it doesn't work in a useful way ;-) If one is thinking about `rm -rf /`, `newfs` is probably the right answer. -T -- I have the attention span of a strobe lit goldfish, please get to the point quickly! -- Seen on Slashdot.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
John Beck, who works for Sun, has posted an entry in his blog yesterday about rm -fr / protection, which I liked a lot: http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: How about: chflags sunlnk / ? _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004 at 04:48:46PM +0200, Dimitry Andric wrote: Of course, your work is commendable, but isn't is much simpler to just not type commands like that? I mean, rm -rf /etc or rm -rf /bin are just as bad, but do you really want to be checking for all possible `bad' deletions? That way, we'll start to look like some software from Redmond... :) `rm -rf /etc` works the way one would expect (removes the etc branch of the filesystem tree). `rm -rf /` is a special case -- it's unlikely to succeed. Additionally, it's a common typo. If it doesn't do what an admin expects, and it's a common typo, removing the ability for it to fail by removing the ability for it to be used makes a lot of sense to me. -T -- Wisdom is not communicable. The wisdom which a wise man tries to communicate always sounds foolish. Hermann Hesse ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-02 11:46, Jacques A. Vidrine [EMAIL PROTECTED] wrote: Will the next step be to prevent `rm -fr *' iff the current working directory is '/' ? Please explain your answer. :-) No. The fact * was passed is not visible to the running program. It's probably better to do this in the shell before it does the wildcard expansion, just like tcsh does. The rm -fr / tmp/foo case *is* visible to the running program though and is a lot easier to handle. I see a lot of people don't like the change, even though I made it default to off and controlled by an environment variable. There's no reason to keep pushing for it, then. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-02 10:51, Tillman Hodgson [EMAIL PROTECTED] wrote: On Sat, Oct 02, 2004 at 10:42:16AM -0500, Sean Farley wrote: Why not default on? root will not run 'rm -rf /' on purpose very often. Once will be enough. :) Also, when and why would someone want to do this? Exactly. Who would expect `rm -rf /` to actually succeed? It's not only dangerous, it doesn't work in a useful way ;-) If one is thinking about `rm -rf /`, `newfs` is probably the right answer. And a hell of a lot faster too. This is the *only* reason why I initially wrote this. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004 at 08:55:17PM +0300, Giorgos Keramidas wrote: On 2004-10-02 10:51, Tillman Hodgson [EMAIL PROTECTED] wrote: If one is thinking about `rm -rf /`, `newfs` is probably the right answer. And a hell of a lot faster too. Exactly. This is the *only* reason why I initially wrote this. I'd love to see it incorporated. -T -- To imagine a human world without ethics, but in which life goes well, it is necessary to suppose a golden age: a world without competition, or causes of strife, or clashing desires, or envy or malice. -- Simon Blackburn (Ruling Passions) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, 2 Oct 2004, Max Laier wrote: I am not a fan of providing seat belts like this. People concerned about Neither am I. One of the best features of UNIX has always been that you can shoot yourself in the foot if you want to. If someone really wants seatbelts, they must be optional. Later.. Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004, Michael Reifenberger wrote: On Sat, 2 Oct 2004, Giorgos Keramidas wrote: Date: Sat, 2 Oct 2004 11:19:28 +0300 From: Giorgos Keramidas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Protection from the dreaded rm -fr / John Beck, who works for Sun, has posted an entry in his blog yesterday about rm -fr / protection, which I liked a lot: http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: This does only help for the obvious case of '/' but not for the './' and '../' or '../../' ... accidents. Furthermore does it prevent root from doing `rm -rf /` which is a pretty legal operation for root since he knows what he is doing. This is UNIX, not Windows. Do you also want to be able to swap to the root partition while it's mounted? We can bring back that feature, too. But personally, I don't see anything wrong with the view that operations that are guaranteed to shoot people in the foot should be disallowed. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004, Jacques A. Vidrine wrote: FWIW, I'm not in favor of adding ad-hoc features to handle edge-cases. (feature because this is actually introducing a bug :-) I picked this email to which to respond, because I can share my own stupidity. Case much like the one described above, but my cronjob included something like: cd /path/to/directory/with/temporary/files rm -fr * Only another admin removed `/path/to/directory/with/temporary/files'... so the `cd' failed and left the current directory as `/'. For some reason the system crashed :-) ... and then crashed again a few days after restoring from backup... doh! Will the next step be to prevent `rm -fr *' iff the current working directory is '/' ? Please explain your answer. :-) Hmm...good point. Since we can never hope to cover *all* the ways for people to shoot themselves in the foot, let's just take off the existing seatbelts. If people try to load old kernel modules, the system will just crash. If they try to mount a device twice, it'll corrupt the filesystem. And of course there's no need to validate buffers passed to the kernel from root, much less even check their length. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, 2 Oct 2004, Giorgos Keramidas wrote: ... Exactly. Who would expect `rm -rf /` to actually succeed? It's not only dangerous, it doesn't work in a useful way ;-) If one is thinking about `rm -rf /`, `newfs` is probably the right answer. ... newfs only works if the root is not mounted because otherwise the device is locked. (Hmm is GEOM too anti foot shooting? But can't you reenable foot-shooting via sysctl?) whereas `rm -rf /` works allwsys :-) Anyway. Check your karma. I've managed to remove large parts of my (and other) various systems several times. Every time this happend I where not concentrated or felt in dangerous safety. Once you realize that there is no seatbelt, you make less errors and have better backups. But many thanks to try to make FreeBSD and its operators better! Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, 2 Oct 2004, Dimitry Andric wrote: Of course, your work is commendable, but isn't is much simpler to just not type commands like that? I mean, rm -rf /etc or rm -rf /bin are just as bad, but do you really want to be checking for all possible `bad' deletions? That way, we'll start to look like some software from Redmond... :) There are many times where sanity checking is an absolute must, but I think it should be implemented in the shell, or a safety later of some kind in those instances where it is necessary, not in the actual workings of the system itself, IMHO. Later.. Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, 2 Oct 2004, David Schultz wrote: ... Do you also want to be able to swap to the root partition while it's mounted? We can bring back that feature, too. But personally, I don't see anything wrong with the view that operations that are guaranteed to shoot people in the foot should be disallowed. Every anti foot shooting takes time to check for. A strncmp for every arg is maybe ok. Traversing the tree for realpath is not. The job for `rm` is to remove whatever it is given to get removed. As fast as possible. Nothing else. Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
* Giorgos Keramidas [EMAIL PROTECTED] [02.10.2004 16:07]: On 2004-10-02 11:51, Giorgos Keramidas [EMAIL PROTECTED] wrote: On 2004-10-02 10:34, Michael Reifenberger [EMAIL PROTECTED] wrote: This does only help for the obvious case of '/' but not for the './' and '../' or '../../' ... accidents. Hmm, indeed. This can be fixed, but it might take a little thinking over about ways to implement it without adding too much overhead to the way rm(1) works now. One way to do that is to use realpath(3), but I have to ask more knowledgeable people about the comment immediately below my change: Other way that may be cheaper is to stat '/', stat each argument and then compare device and inode numbers. wbrw, dmitry. -- Dmitry Frolov [EMAIL PROTECTED] RISS-Telecom Network, Novosibirsk, Russia [EMAIL PROTECTED], +7 3832 NO WA1T, DVF-RIPE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, 2 Oct 2004, Giorgos Keramidas wrote: I see a lot of people don't like the change, even though I made it default to off and controlled by an environment variable. There's no reason to keep pushing for it, then. There's significant support for it, too. As long as it can be disabled, I don't mind it at all. Later.. Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004, Michael Reifenberger wrote: On Sat, 2 Oct 2004, David Schultz wrote: ... Do you also want to be able to swap to the root partition while it's mounted? We can bring back that feature, too. But personally, I don't see anything wrong with the view that operations that are guaranteed to shoot people in the foot should be disallowed. Every anti foot shooting takes time to check for. A strncmp for every arg is maybe ok. Traversing the tree for realpath is not. The job for `rm` is to remove whatever it is given to get removed. As fast as possible. Nothing else. Sigh. The original patch that just used strcmp() wouldn't have increased the time to execute rm by more than a few hundred nanoseconds. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, 2 Oct 2004, David Schultz wrote: Date: Sat, 2 Oct 2004 16:12:11 -0400 From: David Schultz [EMAIL PROTECTED] To: Michael Reifenberger [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Protection from the dreaded rm -fr / On Sat, Oct 02, 2004, Michael Reifenberger wrote: On Sat, 2 Oct 2004, David Schultz wrote: ... Do you also want to be able to swap to the root partition while it's mounted? We can bring back that feature, too. But personally, I don't see anything wrong with the view that operations that are guaranteed to shoot people in the foot should be disallowed. Every anti foot shooting takes time to check for. A strncmp for every arg is maybe ok. Traversing the tree for realpath is not. The job for `rm` is to remove whatever it is given to get removed. As fast as possible. Nothing else. Sigh. The original patch that just used strcmp() wouldn't have increased the time to execute rm by more than a few hundred nanoseconds. Wasn't there a discussion recently to increase ARG_MAX...? :-) Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004 at 09:16:08PM +0200, Michael Reifenberger wrote: On Sat, 2 Oct 2004, Giorgos Keramidas wrote: ... Exactly. Who would expect `rm -rf /` to actually succeed? It's not only dangerous, it doesn't work in a useful way ;-) If one is thinking about `rm -rf /`, `newfs` is probably the right answer. newfs only works if the root is not mounted because otherwise the device is locked. (Hmm is GEOM too anti foot shooting? But can't you reenable foot-shooting via sysctl?) whereas `rm -rf /` works allwsys :-) It'll never work, though, that's the thing. At some point it'll rm something it itself needs and error out. There isn't a way to use `rm -rf /` that /doesn't/ result in foot-shooting. This isn't a sub-tree like /etc or /sbin (which are rooted in /), this is only to treat / itself specially. -T -- If knowledge creates problems, ignorance will not solve them -- Isaac Asimov. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
At 8:57 PM +0300 10/2/04, Giorgos Keramidas wrote: On 2004-10-02 21:23, Lee Harr [EMAIL PROTECTED] wrote: John Beck, who works for Sun, has posted an entry in his blog yesterday about rm -fr / protection, which I liked a lot: http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: How about: chflags sunlnk / ? Setting sunlink on / will only protect the / directory, not its descendants, so you don't gain much. We could add a new flag srunlnk, or maybe even srm-r. The rm command will always have to stat() the file it is given (just to see if it is a directory), so it could check to see if this flag is turned on. If it is turned on, then 'rm' could refuse to honor any '-rf' request on that directory. I like the idea of *some* kind of protection for rm -rf /, but I think it would be better as something more generally useful than protecting against that one single case. While I have typed in a few dozen disastrous rm -rf commands, I have never actually typed in rm -rf /, so this particular seat belt would never have done me any good. By tieing the feature to a settable flag, then I would have the option to protect to other directories (if I wanted to add such protection). -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004 at 05:22:50PM -0400, Garance A Drosihn wrote: At 8:57 PM +0300 10/2/04, Giorgos Keramidas wrote: On 2004-10-02 21:23, Lee Harr [EMAIL PROTECTED] wrote: John Beck, who works for Sun, has posted an entry in his blog yesterday about rm -fr / protection, which I liked a lot: http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: How about: chflags sunlnk / ? Setting sunlink on / will only protect the / directory, not its descendants, so you don't gain much. We could add a new flag srunlnk, or maybe even srm-r. The rm command will always have to stat() the file it is given (just to see if it is a directory), so it could check to see if this flag is turned on. If it is turned on, then 'rm' could refuse to honor any '-rf' request on that directory. I love the idea of this; it's the most elegant solution offered yet. I'm also looking forward to the forthcoming bikeshed regarding exactly what the flag should be called. ;-) Ceri -- It is not tinfoil, it is my new skin. I am a robot. pgpkZ5br1IWD6.pgp Description: PGP signature
Re: Protection from the dreaded rm -fr /
We could add a new flag srunlnk, or maybe even srm-r. The rm command will always have to stat() the file it is given (just to see if it is a directory), so it could check to see if this flag is turned on. If it is turned on, then 'rm' could refuse to honor any '-rf' request on that directory. Why not to just add a flag to 'rm'? For example, `rm -rf /` or `cd; rm -rf .././` will fail, but `rm -rF /` will succeed. Timestamp: 0x415F2702 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-02 21:16, Michael Reifenberger [EMAIL PROTECTED] wrote: Exactly. Who would expect `rm -rf /` to actually succeed? It's not only dangerous, it doesn't work in a useful way ;-) If one is thinking about `rm -rf /`, `newfs` is probably the right answer. newfs only works if the root is not mounted because otherwise the device is locked. No it doesn't. You're just protected by GEOM's locking of the partition table for mounted partitions. (Hmm is GEOM too anti foot shooting? Yes. But can't you reenable foot-shooting via sysctl?) Not via a sysctl, but there is an ioctl to do that now: DIOCSMBR. See revision 1.14 of src/usr.sbin/boot0cfg/boot0cfg.c for an example. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-02 17:22, Garance A Drosihn [EMAIL PROTECTED] wrote: At 8:57 PM +0300 10/2/04, Giorgos Keramidas wrote: On 2004-10-02 21:23, Lee Harr [EMAIL PROTECTED] wrote: How about: chflags sunlnk / ? Setting sunlink on / will only protect the / directory, not its descendants, so you don't gain much. We could add a new flag srunlnk, or maybe even srm-r. The rm command will always have to stat() the file it is given (just to see if it is a directory), so it could check to see if this flag is turned on. If it is turned on, then 'rm' could refuse to honor any '-rf' request on that directory. [...] Hmmm. This sounds much better indeed :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sun, Oct 03, 2004, Giorgos Keramidas wrote: On 2004-10-02 17:22, Garance A Drosihn [EMAIL PROTECTED] wrote: At 8:57 PM +0300 10/2/04, Giorgos Keramidas wrote: On 2004-10-02 21:23, Lee Harr [EMAIL PROTECTED] wrote: How about: chflags sunlnk / ? Setting sunlink on / will only protect the / directory, not its descendants, so you don't gain much. We could add a new flag srunlnk, or maybe even srm-r. The rm command will always have to stat() the file it is given (just to see if it is a directory), so it could check to see if this flag is turned on. If it is turned on, then 'rm' could refuse to honor any '-rf' request on that directory. [...] Hmmm. This sounds much better indeed :-) Give a choice between an elegant 50-line solution involving kernel changes and a somewhat inelegant but complete 3-line solution, I have to say I'd opt for the 3-line solution... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
In message: [EMAIL PROTECTED] Sean Farley [EMAIL PROTECTED] writes: : Why not default on? root will not run 'rm -rf /' on purpose very often. : Once will be enough. :) Also, when and why would someone want to do : this? Please consider chroots. Root many want to do this in a chroot. I'd prefer at the very least rm -rff / to work. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
In message: [EMAIL PROTECTED] Tillman Hodgson [EMAIL PROTECTED] writes: : It'll never work, though, that's the thing. At some point it'll rm : something it itself needs and error out. There isn't a way to use `rm : -rf /` that /doesn't/ result in foot-shooting. No. You are wrong. if you rm -rf in a chroot, then it won't result in foot shooting, necessarily, like it would outside a chroot. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
In message: [EMAIL PROTECTED] Tillman Hodgson [EMAIL PROTECTED] writes: : On Sat, Oct 02, 2004 at 10:42:16AM -0500, Sean Farley wrote: : Why not default on? root will not run 'rm -rf /' on purpose very often. : Once will be enough. :) Also, when and why would someone want to do : this? : : Exactly. Who would expect `rm -rf /` to actually succeed? It's not only : dangerous, it doesn't work in a useful way ;-) I would. I would expect it to work in a chroot I no longer wanted, for example. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On 2004-10-02 19:29, M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Tillman Hodgson [EMAIL PROTECTED] writes: : It'll never work, though, that's the thing. At some point it'll rm : something it itself needs and error out. There isn't a way to use `rm : -rf /` that /doesn't/ result in foot-shooting. No. You are wrong. if you rm -rf in a chroot, then it won't result in foot shooting, necessarily, like it would outside a chroot. Since a chroot can always be rm -fr deleted from outside the chroot, this isn't really a great problem, is it? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
Everyone, If I'm remembering correctly - the historical way to do this is to alias the rm command to something that else that checks the arguments and complains appropriately (and then executes /bin/rm.) Typically with just a shell alias. That keeps you from accidently doing something. Just thinking that putting extra smarts into a utility isn't the typical UNIXy way to do this. Let each tool do the one thing it does really well.. 'rm' removes; let it remove. I think, in the old UNIX Review magazine (what - almost 15+ years ago now?) There was a couple of examples of this. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
In message: [EMAIL PROTECTED] Giorgos Keramidas [EMAIL PROTECTED] writes: : On 2004-10-02 19:29, M. Warner Losh [EMAIL PROTECTED] wrote: : In message: [EMAIL PROTECTED] : Tillman Hodgson [EMAIL PROTECTED] writes: : : It'll never work, though, that's the thing. At some point it'll rm : : something it itself needs and error out. There isn't a way to use `rm : : -rf /` that /doesn't/ result in foot-shooting. : : No. You are wrong. if you rm -rf in a chroot, then it won't result : in foot shooting, necessarily, like it would outside a chroot. : : Since a chroot can always be rm -fr deleted from outside the chroot, : this isn't really a great problem, is it? You miss the point. You said it was always a foot-shooting move. I gave you a concrete example of where it wasn't a foot-shooting move (or even when you could use newfs instead). You reply with a workaround (which may be a valid way to deal, maybe not). My point still stands: it isn't always a foot-shooting move. It isn't a valid work around if you want to delete the chroot from inside the chroot... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, 2 Oct 2004, Thomas David Rivers wrote: If I'm remembering correctly - the historical way to do this is to alias the rm command to something that else that checks the arguments and complains appropriately (and then executes /bin/rm.) Typically with just a shell This would be a much, much better approach. Later.. Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004 at 07:29:51PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Tillman Hodgson [EMAIL PROTECTED] writes: : It'll never work, though, that's the thing. At some point it'll rm : something it itself needs and error out. There isn't a way to use `rm : -rf /` that /doesn't/ result in foot-shooting. No. You are wrong. if you rm -rf in a chroot, then it won't result in foot shooting, necessarily, like it would outside a chroot. If you're chrooted, where is the rm binary and associated libraries? They're in the chroot, in a branch off hte virtual / tree root. `rm -rf /`, even in chroot, won't delete everything that the command looks like it will. At the very least the final unlink, that of / itself, will likely result in undefined behaviour. Where do the dev's go if there's no / to root them in? etc etc. -T -- Waking a person unnecessarily should not be considered a capital crime. For a first offense, that is. -- Robert Heinlein ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004 at 08:14:18PM -0600, Doug Russell wrote: On Sat, 2 Oct 2004, Thomas David Rivers wrote: If I'm remembering correctly - the historical way to do this is to alias the rm command to something that else that checks the arguments and complains appropriately (and then executes /bin/rm.) Typically with just a shell This would be a much, much better approach. For those cases where what is being removed makes sense, I agree. / is a special case, I maintain that the behaviour of `rm -rf` is, by necessity, undefined and unpredictable. `rm` shouldn't be allowed to do it any more than 'rm' should be used to remove user accounts simply because they both invovle removing something. Newfs is the tool for the job in this case. -T -- Great spirits have always found violent opposition from mediocrities. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence.-- Albert Einstein ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
