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: Sudden Reboots
On Fri, Oct 01, 2004 at 08:34:37PM -0700, Bruce R. Montague wrote: proposed. Instead of having a page table entry for each page of virtual address space, these systems have the equivalent of a page table entry for each page of _physical_ memory. All addresses are effectively [...] disk-block. This requires more expensive hardware then a simple addition, but such systems only require a page table entry for every page of physical memory. These systems have been built from early days, but are typically not competitive with VM systems that require simple addition. (I think the IBM AS/400 is the only widely-used commercial hardware using this approach) At some point address space growth, cheap associative lookup memories, and required page table size may make this approach competitive. Actually, all Power and PowerPC chips have this... It's one of the reasons why IBM servers based on these chips can boast very low overheads in several areas. Bye, Andrea -- The best things in life are free, but the expensive ones are still worth a look. ___ [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: Sudden Reboots
Hi, Andrea, regarding inverted page tables: Actually, all Power and PowerPC chips have this... Thanks for pointing that out. I believe the entire line of IBM virtual memory hardware that supports IBM's form of inverted page tables is all directly related, if not the same, and descends from the never-completed 1970s-era IBM Future System (FS) project. Or perhaps it was a version redone for the System/38 that used lessons learned from the FS? Is this right? The AS/400 has successfully used this architecture for a long time. Most of the other systems that have used this architecture (RT, RS) seem to have never quite caught on. Is this VM unit and the Power/PowerPC's the same? They cheat a bit with a hash table to keep the cost of the associative memory down; perhaps increasing its size is the natural evolution of this VM architecture? Are there any true single-level store OSes running on this inverted PT hardware? (That is, where RAM is literally treated as just an invisible performance cache for a secondary-storage primary memory.) I assume the OS/400 is, but maybe an expert knows for sure? OS/400 runs on modern AS/400's which use the PowerPC, unless I'm mistaken... Sorry to have so many questions and no answers, hopefully the coffee will kick in soon. The FS apparently was IBM's biggest failure; some say it had a lot to do with the growth of silicon valley. A history of the IBM Future System and the technologies it spawned would be very interesting. There seems to be little info on it around: www.cs.clemson.edu/~mark/fs.html - bruce ___ [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]
