Re: Amazing.
Did you have any trouble setting up Xorg on it? I recently attempted to upgrade this machine, an old Pentium 2 box, from 4.10 to 5.3 Beta 6 just to take a look at the new features, but whenever I tried to run startx after Xorg -configure had finished running, the screen would flash then simply go back out to the console with the message waiting for the X server to shut down. I tried all kinds of things to make it work, but no go. Any ideas what I could be missing, anyone? Frank Mayhar [EMAIL PROTECTED] wrote: I just want to drop a line to you folks (and to Bill Paul in particular) to express my appreciation for your work. I received my new laptop today after my old one finally succumbed to a combination of old age and ancient coffee spills. I installed 5.3-BETA6 on it immediately, no trouble, it knew about the Broadcom NIC out of the box and I did a quick check to learn how to set up ndis so I could use the Dell (actually Broadcom) wireless NIC as well. Built ndis, converted the Windows driver, built if_ndis, installed it, loaded it, configured the interface, ran dhclient and I'm using it as I type this. Took maybe an hour, including burning the driver and /usr/src on a DVD to carry into the living room. I was so impressed that I just had to write and say so. Kudos to you guys. You do good work. After having had to deal with the insides of Linux for the last year, it's a pleasure to use a system that is built with such professionalism. Thanks! -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] - Do you Yahoo!? vote.yahoo.com - Register online to vote today! ___ [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: Amazing.
jason features, but whenever I tried to run startx after Xorg -configure had finished jason running, the screen would flash then simply go back out to the console with the The X server's log (/var/log/X*.log) should tell you what went wrong. A common problem is that you are trying to run X without the appropriate permissions. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Wired memory monitoring
Hello, I am investigating some VM issues on FreeBSD. I have noticed that wired memory grows quite rapidly on forking lots of processes. After those processes exit, it drops a bit, but still can use about 100MB after launching 3000 processes. I think it's not a leak, as subsequent forks don't cause it to grow noticeably. I'm rather curious what eats all that memory. sysctl vm.zone shows some high values, but they're are not high in memory usage terms, even considering 50% (or so) efficiency of the slab allocator. The question is, are there any other memory inspecting tools that would allow me to see where is all that wired memory? And, are there any ways to control it's behaviour (eg. to free unused per-process structures and data)? greetings, -- Jan 'Winfried' Srzednicki [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, 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: GEOM (ggate) compression consumer +problem
* Ivan Voras [EMAIL PROTECTED] [01.10.2004 17:17]: But, I still can't solve the wdrain problem. I've tried it on a recent BETA6 kernel and it still remains. Writes get slower and slower (actually, the frequency of writes), and then something locks up (with no CPU usage...). Sometimes, *any* writes to any filesystem lock up. Looks very similar to a syncing problem found in md(4). Take a look at cvs log entry for revision 1.115 of md.c: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/md/md.c 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 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: GEOM (ggate) compression consumer +problem
Dmitry Frolov wrote: * Ivan Voras [EMAIL PROTECTED] [01.10.2004 17:17]: But, I still can't solve the wdrain problem. I've tried it on a recent BETA6 kernel and it still remains. Writes get slower and slower (actually, the frequency of writes), and then something locks up (with no CPU usage...). Sometimes, *any* writes to any filesystem lock up. Looks very similar to a syncing problem found in md(4). Take a look at cvs log entry for revision 1.115 of md.c: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/md/md.c Thank you! It's exactly the same problem I've got. After including O_DIRECT and O_FSYNC flags to the open() call, the problems dissapear (though performance takes a big hit). Also, it's the same problem with ggatel. This small patch solves it: --- ggatel.c.oldSat Oct 2 16:48:08 2004 +++ ggatel.cSat Oct 2 16:48:11 2004 @@ -160,7 +160,7 @@ struct g_gate_ctl_create ggioc; int fd; - fd = open(path, g_gate_openflags(flags)); + fd = open(path, g_gate_openflags(flags) | O_DIRECT | O_FSYNC); if (fd 0) err(EXIT_FAILURE, Cannot open %s, path); ggioc.gctl_version = G_GATE_VERSION; I've poslihed some quirks from the ggatec, so it should now be ready for somewhat broader testing ;) (It's at http://ivoras.sharanet.org/ggcomp.tgz ; expect about 10x worse performance compared to performance without compression). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Probing PCI devices not detected by BIOS
Hi, In FreeBSD 4.x, is there an option to probe PCI devices not detected by BIOS? My problem: I have an old ASUS P2B-DS motherboard based server, and want to use a Realtek 8169 Gigabit LAN Card with it. But the BIOS does not detect the LAN card, I don't know why. If I put the card in another computer, it is detected perfectly. Unless this is a hardware incompatibility problem, I would expect FreeBSD to do a better job than the old BIOS. I would rather have an Intel card, but they not available around. :-( Jonny -- João Carlos Mendes Luís - Networking Engineer - [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 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: Sudden Reboots
On Thu, 30 Sep 2004, Jim Durham wrote: I have had this problem now with at least 3 FreeBSD servers over a period of about 2 years. I had put it down to some hardware problem but it seems to be too much of a coincidence with 3 different machines doing the same thing. I had sudden reboots over a period of two years. Recently, they started happening more often. It turned out that the capacitors had gone bad. Capacitors from about two to three years ago used a poor formula. This site has information about it: http://www.badcaps.net/. The interesting thing for me was that the capacitors did not show any signs for about two years. They looked like they had flat tops without leaking. I think they may have spilled their guts when, I turned the computer off for about a week for a vacation. They must have missed me. :) In case the power supplies are over-taxed, here is an on-line calculator: http://takaman.jp/D/index.html?english. 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 /
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: Wired memory monitoring
Jan Srzednicki wrote: Hello, I am investigating some VM issues on FreeBSD. I have noticed that wired memory grows quite rapidly on forking lots of processes. After those processes exit, it drops a bit, but still can use about 100MB after launching 3000 processes. I think it's not a leak, as subsequent forks don't cause it to grow noticeably. I'm rather curious what eats all that memory. sysctl vm.zone shows some high values, but they're are not high in memory usage terms, even considering 50% (or so) efficiency of the slab allocator. The question is, are there any other memory inspecting tools that would allow me to see where is all that wired memory? And, are there any ways to control it's behaviour (eg. to free unused per-process structures and data)? greetings, Wouldn't that be the zone allocator grabbing pages from the free list and adding them to non-pagable per process structures? -- 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 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: Wired memory monitoring
Jan Srzednicki wrote: Hello, I am investigating some VM issues on FreeBSD. I have noticed that wired memory grows quite rapidly on forking lots of processes. After those processes exit, it drops a bit, but still can use about 100MB after launching 3000 processes. I think it's not a leak, as subsequent forks don't cause it to grow noticeably. I'm rather curious what eats all that memory. sysctl vm.zone shows some high values, but they're are not high in memory usage terms, even considering 50% (or so) efficiency of the slab allocator. The question is, are there any other memory inspecting tools that would allow me to see where is all that wired memory? And, are there any ways to control it's behaviour (eg. to free unused per-process structures and data)? greetings, Every thread allocated only shows the thread structure in the zone stats but there is a 3 page stack allocated with it too which doesn't show up there. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wired memory monitoring
Julian Elischer wrote: Jan Srzednicki wrote: Hello, I am investigating some VM issues on FreeBSD. I have noticed that wired memory grows quite rapidly on forking lots of processes. After those processes exit, it drops a bit, but still can use about 100MB after launching 3000 processes. I think it's not a leak, as subsequent forks don't cause it to grow noticeably. I'm rather curious what eats all that memory. sysctl vm.zone shows some high values, but they're are not high in memory usage terms, even considering 50% (or so) efficiency of the slab allocator. The question is, are there any other memory inspecting tools that would allow me to see where is all that wired memory? And, are there any ways to control it's behaviour (eg. to free unused per-process structures and data)? greetings, Every thread allocated only shows the thread structure in the zone stats but there is a 3 page stack allocated with it too which doesn't show up there. this is in 5.x 6.x.. you don't say what version you are looking at. ___ [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, 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: Sudden Reboots
On Sat, 2 Oct 2004, Sean Farley wrote: I had sudden reboots over a period of two years. Recently, they started happening more often. It turned out that the capacitors had gone bad. Capacitors from about two to three years ago used a poor formula. This site has information about it: http://www.badcaps.net/. Even the best quality new ones can wear out and cause these problems with only the smallest of defects inside eventually making them unusable for the type of circuitry they're used in. (The current pulse demands on these caps in switching regulators are absolutely rediculous). I've got a whole little plastic bin full of them to replace ones on bad boards. When you order them, look very closely at the specifications, especially at how much current they're rated to handle for a given value, and get the ones with the highet current rating, even if you have to go with a higher voltage (I often use 10v caps to replace 6.3v ones when they'll fit, as the particular brands I've been using have significantly higher current capability for the same uF value), and perhaps go with a slightly higher uF value (really helps to understand the circuit, though. Don't go TOO much higher than the original value). The interesting thing for me was that the capacitors did not show any signs for about two years. They looked like they had flat tops without Sure... and these types of problems often show up only after being powered off for some time, etc. The OP said two of his boxes mysteriously fixed themselves. Just because they haven't failed for some time doesn't mean there isn't still something flakey in there. His problems REALLY sound to me like capacitor problems in the PSU or, more likely, the voltage regulators on the motherboard. Seen this type of problem many, many times. Having an ESR tester is handy, also. 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, 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: Sudden Reboots
On Fri, 1 Oct 2004 21:50:26 -0500, in sentex.lists.freebsd.hackers you wrote: On Oct 1, 2004, at 7:23 PM, Jim Durham wrote: These are very rare except they seem to happen about once a day for a while and then stop... very strange.. and usually caused by hardware problems (e.g. faulty power supply, overheating CPU, bad RAM). Possible, but if so, the hardware fixed itself on the first two boxes I mentioned. All of this can be bad, or not quite bad -- just not healthy -- hardware. Say a power supply that can't supply reliable +5, when the line voltage drops a tad while all the disks are being hammered. It can be a nightmare to figure out. Setup crash dumps, but also make sure that the UPS the box is attached to isn't having problems. If it's not on conditioned power, fix that. Also, a lot of older UPSes do not have any AVR (automatic voltage regulation). This in conjunction with a marginal power supply can cause problems like you describe. One of our POPs are in an area that has seen tremendous residential and industrial growth putting a strain on the local power. Prior to some major upgrades from the local utility company, we would see street power dropping below 100V during peak usage coming from the street and our APCs that have smart boost would all kick in to compensate. Also, the UPS can just be bad over time. As others have said, its pretty rare that reboots do not leave a crash dump behind when its a software issue. At the very least, enable crash dumps on your machines in question. See the man page for dumpon. At least this way you can narrow down the odds as to whether or not its pointing to a hardware or software issue. ---Mike ___ [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: Protecting from the dreaded rm -fr /
On Sun, Oct 03, 2004 at 00:20 , Men gasped, women fainted, and small children were reduced to tears as [EMAIL PROTECTED] confessed to all: Message: 2 Date: Sat, 2 Oct 2004 22:43:49 +1000 From: Peter Jeremy [EMAIL PROTECTED] Subject: Re: Protection from the dreaded rm -fr / To: Giorgos Keramidas [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii 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. You can always trust the computer to do exactly what you tell it to, even if what you told it to was not what you wanted it to do. If you customer tested the program on non production machines and it failed on the production machine then it was obvious the customer made the mistake of re-creating the crontab line instead of copying it over. The way to keep from shooting yourself in the foot is 1) always check with an 'ls' argument before doing any exterme wildcarding and if you like what you see use your shell editing to change 'ls' to 'rm'. 2) is to let the end user know that certain things are very dangerous and they could destory their system, 3) have automated and verified backups run on the complet system every night. I've been using Unix too long to want to see this behaviour changed, and I'll use the same argument that others do when they advise against aliasing rm to rm -i. If you know that you can't shoot yourself in the foot, you will not treat rm as if it were a loaded automatic pistol and you don't reinforce your double checking. Then one day you go to a machine that doesn't have the safety-net and you make a mistake and it won't be recoverable. If we could arrange to change all the rm's on all the Unix machines in the world at the same - maybe then I'd go for it :-) Bill -- Bill Vermillion - bv @ wjv . 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] 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: Probing PCI devices not detected by BIOS
In message: [EMAIL PROTECTED] João Carlos Mendes Luís [EMAIL PROTECTED] writes: : My problem: I have an old ASUS P2B-DS motherboard based server, and want to : use a Realtek 8169 Gigabit LAN Card with it. But the BIOS does not detect the : LAN card, I don't know why. If I put the card in another computer, it is : detected perfectly. Unless this is a hardware incompatibility problem, I would : expect FreeBSD to do a better job than the old BIOS. Chances are good that you might have a problem. I have a few devices that don't appear on one of my machines because the machines are too old and not compliant with the latest PCI standards. I also have one cardbus card that refuses to work on some machine due to, I think, bad (no?) 3.3V power. 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: Probing PCI devices not detected by BIOS
M. Warner Losh wrote: In message: [EMAIL PROTECTED] João Carlos Mendes Luís [EMAIL PROTECTED] writes: : My problem: I have an old ASUS P2B-DS motherboard based server, and want to : use a Realtek 8169 Gigabit LAN Card with it. But the BIOS does not detect the : LAN card, I don't know why. If I put the card in another computer, it is : detected perfectly. Unless this is a hardware incompatibility problem, I would : expect FreeBSD to do a better job than the old BIOS. Chances are good that you might have a problem. I have a few devices that don't appear on one of my machines because the machines are too old and not compliant with the latest PCI standards. I also have one cardbus card that refuses to work on some machine due to, I think, bad (no?) 3.3V power. There are currently three PCI standards, not including PCI-X. PCI2.1, PCI2.2, PCI2.3. (Again, not including PCI-X, this is only 32bit/33MHz.) On top of this, you have three voltage standards; PCI 5V, PCI3.3V, and PCI-Universal (3.3/5.) These are the -keying- of the slots. So I got out the PCI 2.3 specs, go to pp185. A PCI 2.3 slot is keyed at the front (towards the front of the case), as the P2B-DS is, and is 5V. A PCI 3.3V slot is keyed towards the rear (towards the I/O panel). Then there's PCI Universal; this a card-only specification, which has a double-keyed card (keyed front -and- rear) to be inserted in 3.3V or 5V slot. A universally keyed card should support either 3.3V -or- 5V normally. The Realtek 8169's I've seen are keyed universal, but is specifically a PCI 2.2 or later 3.3V card. A universal keyed PCB is apparently cheaper to make than a properly keyed card. The Asus P2B-DS is, as far as I have been able to find, a PCI 2.1 board. -ksaihr ___ [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]
