Re: rm(1) bug, possibly serious
On Thu, 27 Sep 2007, Mark Andrews wrote: (I wrote:) On Tue, 25 Sep 2007, LI Xin wrote: Oliver Fromme wrote: Nicolas Rachinsky wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Clearly a bug, and well spotted, especially if as old as reported. Adding a slash often leads to different behaviour. Yes, I'm aware of that. I often make use of the feature that find /sys/ expands the symlink, while find /sys does not. The same holds true for ls(1). But fortunately not for rm(1): The rm utility removes symbolic links, not the files referenced by the links. It is an error to attempt to remove the files /, . or .. However, I would still argue that there is no sane reason for rm -rf ../ behaving differently from rm -rf .., especially because it behaves differently in a destructive way. That's why I call it a POLA violation. Also a POSIX violation IMHO :-) Indeed; I can't imagine a situation where removing . (let alone ..) and so orphaning the pwd might be considered sane, never mind legal .. but maybe I lack imagination :) You lack imagination. No doubt :) When you found the directory you want to remove and you are in it it is much less error prone to remove . recursively that to go up one directory and try to find the directory you were just in. Sorry, I can't agree. I take comfort in knowing that 'rm .' will fail, that 'rm *' will not remove '.' (let alone '..'!), and that rm will not orphan the pwd. Neither will umount, for that matter .. You asked to be shown a example. It's a perfectly reasonable example. The the prohibitions comes from when you literally removed directories by unlinking the directory and . and .. within the directory in user space. It was easy to stuff up a directory structure. Regardless of how implemented in the filesystem, having the pwd become invalid isn't something I ever expect to happen, and I'll continue to rely on: 'It is an error to attempt to remove the files /, . or ..' It's something that you need to expect on a multi-process system. It happens to me one or twice a month. Mark Cheers, Ian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On Thu, 27 Sep 2007, Mark Andrews wrote: (I wrote:) On Tue, 25 Sep 2007, LI Xin wrote: Oliver Fromme wrote: Nicolas Rachinsky wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Clearly a bug, and well spotted, especially if as old as reported. Adding a slash often leads to different behaviour. Yes, I'm aware of that. I often make use of the feature that find /sys/ expands the symlink, while find /sys does not. The same holds true for ls(1). But fortunately not for rm(1): The rm utility removes symbolic links, not the files referenced by the links. It is an error to attempt to remove the files /, . or .. However, I would still argue that there is no sane reason for rm -rf ../ behaving differently from rm -rf .., especially because it behaves differently in a destructive way. That's why I call it a POLA violation. Also a POSIX violation IMHO :-) Indeed; I can't imagine a situation where removing . (let alone ..) and so orphaning the pwd might be considered sane, never mind legal .. but maybe I lack imagination :) You lack imagination. No doubt :) When you found the directory you want to remove and you are in it it is much less error prone to remove . recursively that to go up one directory and try to find the directory you were just in. Sorry, I can't agree. I take comfort in knowing that 'rm .' will fail, that 'rm *' will not remove '.' (let alone '..'!), and that rm will not orphan the pwd. Neither will umount, for that matter .. The the prohibitions comes from when you literally removed directories by unlinking the directory and . and .. within the directory in user space. It was easy to stuff up a directory structure. Regardless of how implemented in the filesystem, having the pwd become invalid isn't something I ever expect to happen, and I'll continue to rely on: 'It is an error to attempt to remove the files /, . or ..' Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
Bob Johnson wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Maybe. But I expect that the behavior for rm -rf .. is there so that things don't get REALLY astonishing when you do rm -rf *. The expansion of * does not include . or ... (As a side note, i also think that a tool should not try to mess with shell expansion, or make assumptions about it. For example, most shells have an optional feature to ask for confirmation when the user typed rm * or similar. If a user wants such protection, he can enable it. There is no reason that rm(1) or other tools try to be clever about it.) Having a different behavior for rm -rf ../ may have been intentional on someone's part so you can override the protection if you really want to. If it was intentional, then there wouldn't be a misleading error message (and exit code 1). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The last good thing written in C was Franz Schubert's Symphony number 9. -- Erwin Dieterich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On Tue, 25 Sep 2007, LI Xin wrote: Oliver Fromme wrote: Nicolas Rachinsky wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Clearly a bug, and well spotted, especially if as old as reported. Adding a slash often leads to different behaviour. Yes, I'm aware of that. I often make use of the feature that find /sys/ expands the symlink, while find /sys does not. The same holds true for ls(1). But fortunately not for rm(1): The rm utility removes symbolic links, not the files referenced by the links. It is an error to attempt to remove the files /, . or .. However, I would still argue that there is no sane reason for rm -rf ../ behaving differently from rm -rf .., especially because it behaves differently in a destructive way. That's why I call it a POLA violation. Also a POSIX violation IMHO :-) Indeed; I can't imagine a situation where removing . (let alone ..) and so orphaning the pwd might be considered sane, never mind legal .. but maybe I lack imagination :) Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
In the last episode (Sep 26), Oliver Fromme said: Bob Johnson wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Maybe. But I expect that the behavior for rm -rf .. is there so that things don't get REALLY astonishing when you do rm -rf *. The expansion of * does not include . or ... Under /bin/sh, .* does match . and .., so be careful :) -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
Dan Nelson wrote: In the last episode (Sep 26), Oliver Fromme said: Bob Johnson wrote: Maybe. But I expect that the behavior for rm -rf .. is there so that things don't get REALLY astonishing when you do rm -rf *. The expansion of * does not include . or ... Under /bin/sh, .* does match . and .., so be careful :) .??* is a standard workaround that works most of the time. Won't match .a .b etc but such antisocial files are the exception, one might hope. --Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
Dan Nelson wrote: Oliver Fromme said: The expansion of * does not include . or ... Under /bin/sh, .* does match . and .., so be careful :) For that reason I got used to type .??* instead of .* since I started with UNIX almost 20 years ago. ;-) Apart from that, zsh is my shell of choice. It never matches . or .. with any globbing patterns. I think no shell should. I would submit an appropriate patch for FreeBSD's sh if it would be committed, but I doubt it would. Even this discussion here about an obvious bug in rm has bikeshed tendencies. :-( Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++: an octopus made by nailing extra legs onto a dog -- Steve Taylor, 1998 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[OT] Re: rm(1) bug, possibly serious
Alex Zbyslaw wrote: .??* is a standard workaround that works most of the time. Won't match .a .b etc but such antisocial files are the exception, one might hope. What? I name all my files that way! Granted, that only allows under 30 files per directory, but so what? -- Tuomo ... SROL Alright! I just gave advice on which underwear/bra combo to wear to a party to my New York ho :D TheBaskinator What's his name? -- http://bash.org/?81736 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On 9/26/07, Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Sep 26), Oliver Fromme said: Bob Johnson wrote: Maybe. But I expect that the behavior for rm -rf .. is there so that things don't get REALLY astonishing when you do rm -rf *. The expansion of * does not include . or ... Under /bin/sh, .* does match . and .., so be careful :) That's what I meant... thanks. Applies to bash, too. - Bob ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On Tue, 25 Sep 2007, LI Xin wrote: I think this is a bug, here is a fix obtained from NetBSD. This bug, if any, cannot be fixed in rm. The reasoning (from NetBSD's rm.c,v 1.16): Bugs can easily be added to rm. Strip trailing slashes of operands in checkdot(). POSIX.2 requires that if . or .. are specified as the basename portion of an operand, a diagnostic message be written to standard error, etc. Note that POSIX only requires this for the rm utility. (See my previous mail about why this is bogus.) Pathname resolution and a similarly bogus restriction on rmdir(2) requires some operations with dot or dot-dot to fail, and any utility that uses these operations should then print a diagnostic, etc. We strip the slashes because POSIX.2 defines basename as the final portion of a pathname after trailing slashes have been removed. POSIX says the basename portion of the operand (that is, the final pathname component. This doesn't mean the operand mangled by basename(3). This also makes rm perform actions equivalent to the POSIX.1 rmdir() and unlink() functions when removing directories and files, even when they do not follow POSIX.1's pathname resolution semantics (which require trailing slashes be ignored). Which POSIX.1? POSIX.1-2001 actually requires trailing slashes shall be resolved as if a single dot character were appended to the pathname. This is completely different from removing the slash: rm regular file/# ENOTDIR rm regular file # success unless ENOENT etc. rm directory/ # success... rm directory# EISDIR rm symlink to regular file/ # ENOTDIR rm symlink to regular file # success (removes symlink) rm symlink to directory/# EISDIR rm symlink to directory # success (removes symlink) rmdir ... # reverse most of above Anyway, mangling the operands makes the utilities perform actions different from the functions. The problem case is rm -r symlink to directory/ which asks for removing the directory pointed to by the symlink and all its contents, and is useful -- you type the trailing symlink if you want to ensure that the removal is as recursive as possible. With breakage of rmdir(2) to POSIX spec, this gives removal the contents of the directory pointed to be the symlink and then fails to remove the directory. With breakage as in NetBSD, this gives removal of the symlink only. If nobody complains about this I will request for commit approval from [EMAIL PROTECTED] ++ Bruce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On Tue, 25 Sep 2007, LI Xin wrote: Oliver Fromme wrote: Nicolas Rachinsky wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Clearly a bug, and well spotted, especially if as old as reported. Adding a slash often leads to different behaviour. Yes, I'm aware of that. I often make use of the feature that find /sys/ expands the symlink, while find /sys does not. The same holds true for ls(1). But fortunately not for rm(1): The rm utility removes symbolic links, not the files referenced by the links. It is an error to attempt to remove the files /, . or .. However, I would still argue that there is no sane reason for rm -rf ../ behaving differently from rm -rf .., especially because it behaves differently in a destructive way. That's why I call it a POLA violation. Also a POSIX violation IMHO :-) Indeed; I can't imagine a situation where removing . (let alone ..) and so orphaning the pwd might be considered sane, never mind legal .. but maybe I lack imagination :) You lack imagination. When you found the directory you want to remove and you are in it it is much less error prone to remove . recursively that to go up one directory and try to find the directory you were just in. The the prohibitions comes from when you literally removed directories by unlinking the directory and . and .. within the directory in user space. It was easy to stuff up a directory structure. Mark Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
rm(1) bug, possibly serious
Hi, Today I noticed the following behaviour on a 6-stable machine: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ rm -rf ../ $ Note that the command rm -rf ../ was entered twice. The first time I got an error message (and exit code 1), the second time it apparently succeeded. The very same command. Further investigation: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ ls -al .. ls: ..: No such file or directory $ ls /tmp/foo/bar ls: /tmp/foo/bar: No such file or directory That means: Even though rm -rf ../ prints an error message, indicating that the argument is invalid, it *DOES* remove the contents of the parent directory! To add further confusion, another rm -rf ../ does not print an error message and seemingly succeeds, even though .. does not exist anymore in the current directory (which has been removed). Shall I file a PR? Or is rm working correctly, and my assumptions are wrong? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired. -- Chris Torek ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On 9/25/07, Oliver Fromme [EMAIL PROTECTED] wrote: Hi, Today I noticed the following behaviour on a 6-stable machine: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ rm -rf ../ $ Note that the command rm -rf ../ was entered twice. The first time I got an error message (and exit code 1), the second time it apparently succeeded. The very same command. Further investigation: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ ls -al .. ls: ..: No such file or directory $ ls /tmp/foo/bar ls: /tmp/foo/bar: No such file or directory That means: Even though rm -rf ../ prints an error message, indicating that the argument is invalid, it *DOES* remove the contents of the parent directory! To add further confusion, another rm -rf ../ does not print an error message and seemingly succeeds, even though .. does not exist anymore in the current directory (which has been removed). Shall I file a PR? Or is rm working correctly, and my assumptions are wrong? Best regards Oliver Confirmed on CURRENT as well. Note that if you run rf -rf .. as the first command, the command does fail with 'rm: . and .. may not be removed'. Adding a / at the end does seem to get around this check. - Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On Tue, Sep 25, 2007 at 05:12:50PM +0200, Oliver Fromme wrote: Hi, Today I noticed the following behaviour on a 6-stable machine: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar Looks like you have mistyped 'mkdir' argument :) $ rm -rf ../ rm: ../: Invalid argument Please type 'pwd' here $ rm -rf ../ $ Note that the command rm -rf ../ was entered twice. The first time I got an error message (and exit code 1), the second time it apparently succeeded. The very same command. Further investigation: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ ls -al .. ls: ..: No such file or directory $ ls /tmp/foo/bar ls: /tmp/foo/bar: No such file or directory That means: Even though rm -rf ../ prints an error message, indicating that the argument is invalid, it *DOES* remove the contents of the parent directory! To add further confusion, another rm -rf ../ does not print an error message and seemingly succeeds, even though .. does not exist anymore in the current directory (which has been removed). Shall I file a PR? Or is rm working correctly, and my assumptions are wrong? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, GeschДftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht MЭn- chen, HRB 125758, GeschДftsfЭhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired. -- Chris Torek -- The ultimate artifact may be found in the driven snow... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On Tue, 25 Sep 2007 17:12:50 +0200 (CEST) Oliver Fromme [EMAIL PROTECTED] wrote: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ rm -rf ../ $ Note that the command rm -rf ../ was entered twice. The first time I got an error message (and exit code 1), the second time it apparently succeeded. The very same command. What happens if you issue a 'pwd' command after each 'rm -rf ../'? We want to see the output. IMHO, the only way the second rm command *should* succeed, is if it invalidates the current working directory, thus releasing the last lock on the directory. Quick testing here: [EMAIL PROTECTED] mkdir -p foo/bar [EMAIL PROTECTED] cd foo/bar [EMAIL PROTECTED] ll total 4 drwxr-xr-x 2 tingo wheel - 512 Sep 25 17:31 ./ drwxr-xr-x 3 tingo wheel - 512 Sep 25 17:31 ../ [EMAIL PROTECTED] pwd /tmp/foo/bar [EMAIL PROTECTED] rm -rf ../ rm: ../: Invalid argument [EMAIL PROTECTED] pwd /tmp/foo/bar [EMAIL PROTECTED] rm -rf ../ [EMAIL PROTECTED] pwd /tmp/foo/bar [EMAIL PROTECTED] ls -al total 0 [EMAIL PROTECTED] ll total 0 [EMAIL PROTECTED] pwd /tmp/foo/bar [EMAIL PROTECTED] ls -al .. ls: ..: No such file or directory [EMAIL PROTECTED] ls -al /tmp/foo/bar ls: /tmp/foo/bar: No such file or directory [EMAIL PROTECTED] ls -al /tmp/foo total 8 drwxr-xr-x 2 tingo wheel 512 Sep 25 17:32 . drwxrwxrwt 35 root wheel 5632 Sep 25 17:31 .. Ok, I think it is a bug. -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On Tue, 25 Sep 2007, Oliver Fromme wrote: Note that the command rm -rf ../ was entered twice. The first time I got an error message (and exit code 1), the second time it apparently succeeded. Check the man page for rm: -f Attempt to remove the files without prompting for confirma- tion, regardless of the file's permissions. If the file does not exist, do not display a diagnostic message or modify the exit status to reflect an error. That's what's happening the second time through. The first time, your current directory is getting removed (so ../ won't refer to a real directory the second time around). The bug is really in rm(1)'s initial diagnostic message. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ We thought time travel was impossible. But that was now and this is then. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
Torfinn Ingolfsen wrote: Oliver Fromme wrote: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ rm -rf ../ $ Note that the command rm -rf ../ was entered twice. The first time I got an error message (and exit code 1), the second time it apparently succeeded. The very same command. What happens if you issue a 'pwd' command after each 'rm -rf ../'? We want to see the output. It's /tmp/foo/bar every time. IMHO, the only way the second rm command *should* succeed, is if it invalidates the current working directory, thus releasing the last lock on the directory. Quick testing here: [...] Ok, I think it is a bug. Yes, I think so, too. By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl will consistently give you what you want, unless what you want is consistency. -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
I think this is a bug, here is a fix obtained from NetBSD.
The reasoning (from NetBSD's rm.c,v 1.16):
Strip trailing slashes of operands in checkdot().
POSIX.2 requires that if . or .. are specified as the basename
portion of an operand, a diagnostic message be written to standard
error, etc. We strip the slashes because POSIX.2 defines basename
as the final portion of a pathname after trailing slashes have been
removed.
This also makes rm perform actions equivalent to the POSIX.1
rmdir() and unlink() functions when removing directories and files,
even when they do not follow POSIX.1's pathname resolution semantics
(which require trailing slashes be ignored).
If nobody complains about this I will request for commit approval from [EMAIL
PROTECTED]
Cheers,
--
Xin LI [EMAIL PROTECTED] http://www.delphij.net/
FreeBSD - The Power to Serve!
Index: rm.c
===
RCS file: /home/ncvs/src/bin/rm/rm.c,v
retrieving revision 1.58
diff -u -p -r1.58 rm.c
--- rm.c31 Oct 2006 02:22:36 - 1.58
+++ rm.c25 Sep 2007 18:26:52 -
@@ -558,6 +558,14 @@ check2(char **argv)
return (first == 'y' || first == 'Y');
}
+/*
+ * POSIX.2 requires that if . or .. are specified as the basename
+ * portion of an operand, a diagnostic message be written to standard
+ * error and nothing more be done with such operands.
+ *
+ * Since POSIX.2 defines basename as the final portion of a path after
+ * trailing slashes have been removed, we'll remove them here.
+ */
#define ISDOT(a) ((a)[0] == '.' (!(a)[1] || ((a)[1] == '.'
!(a)[2])))
void
checkdot(char **argv)
@@ -567,10 +575,17 @@ checkdot(char **argv)
complained = 0;
for (t = argv; *t;) {
+ /* strip trailing slashes */
+ p = strrchr(*t, '\0');
+ while (--p *t *p == '/')
+ *p = '\0';
+
+ /* extract basename */
if ((p = strrchr(*t, '/')) != NULL)
++p;
else
p = *t;
+
if (ISDOT(p)) {
if (!complained++)
warnx(\.\ and \..\ may not be removed);
signature.asc
Description: OpenPGP digital signature
Re: rm(1) bug, possibly serious
* Oliver Fromme [EMAIL PROTECTED] [2007-09-25 19:43 +0200]: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Adding a slash often leads to different behaviour. [EMAIL PROTECTED] ~/rd mkdir foo; ln -s foo bar [EMAIL PROTECTED] ~/rd rm -r bar [EMAIL PROTECTED] ~/rd ls -l total 2 drwxr-xr-x 2 nicolas wheel 512 Sep 25 20:55 foo/ [EMAIL PROTECTED] ~/rd [EMAIL PROTECTED] ~/rd mkdir foo; ln -s foo bar [EMAIL PROTECTED] ~/rd rm -r bar/ [EMAIL PROTECTED] ~/rd ls -l total 0 lrwxr-xr-x 1 nicolas wheel 3 Sep 25 20:56 bar@ - foo [EMAIL PROTECTED] ~/rd And cp -R behaves differently for dir and dir/, too, but it is explicitly documented there. Nicolas -- http://www.rachinsky.de/nicolas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
Nicolas Rachinsky wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Adding a slash often leads to different behaviour. Yes, I'm aware of that. I often make use of the feature that find /sys/ expands the symlink, while find /sys does not. The same holds true for ls(1). However, I would still argue that there is no sane reason for rm -rf ../ behaving differently from rm -rf .., especially because it behaves differently in a destructive way. That's why I call it a POLA violation. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is executable pseudocode. Perl is executable line noise. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
Oliver Fromme wrote: Nicolas Rachinsky wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Adding a slash often leads to different behaviour. Yes, I'm aware of that. I often make use of the feature that find /sys/ expands the symlink, while find /sys does not. The same holds true for ls(1). However, I would still argue that there is no sane reason for rm -rf ../ behaving differently from rm -rf .., especially because it behaves differently in a destructive way. That's why I call it a POLA violation. Also a POSIX violation IMHO :-) Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: rm(1) bug, possibly serious
Hi, On Tue, Sep 25, 2007 at 11:25:34AM -0400, Maxim Khitrov wrote: On 9/25/07, Oliver Fromme [EMAIL PROTECTED] wrote: To add further confusion, another rm -rf ../ does not print an error message and seemingly succeeds, even though .. does not exist anymore in the current directory (which has been removed). Confirmed on CURRENT as well. Note that if you run rf -rf .. as the first command, the command does fail with 'rm: . and .. may not be removed'. Adding a / at the end does seem to get around this check. May I add some more confusion? In tcsh: (23:49) [EMAIL PROTECTED]:ttyp2 [~] which rm /bin/rm (23:49) [EMAIL PROTECTED]:ttyp2 [~] cd /tmp (23:49) [EMAIL PROTECTED]:ttyp2 [/tmp] mkdir -p foo/bar (23:49) [EMAIL PROTECTED]:ttyp2 [/tmp] cd foo/bar (23:49) [EMAIL PROTECTED]:ttyp2 [foo/bar] rm -rf ../ (23:49) [EMAIL PROTECTED]:ttyp2 [foo/bar] pwd pwd: .: No such file or directory (23:52) [EMAIL PROTECTED]:ttyp2 [foo/bar] cd /tmp (23:52) [EMAIL PROTECTED]:ttyp2 [/tmp] ls (23:52) [EMAIL PROTECTED]:ttyp2 [/tmp] In sh: $ which rm /bin/rm $ cd /tmp $ mkdir -p foo/bar $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ pwd /tmp/foo/bar $ rm -rf ../ $ pwd /tmp/foo/bar $ cd /tmp $ ls foo $ cd foo $ ls (23:53) [EMAIL PROTECTED]:ttyp2 [~] uname -a FreeBSD nowhere.ob-home.lan 6.2-STABLE FreeBSD 6.2-STABLE #17: Sun Aug 5 19:03:13 CEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NOWHERE i386 - Olli -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | pgpR1kZ5k8oxV.pgp Description: PGP signature
Re: rm(1) bug, possibly serious
Hello! On Tue, Sep 25, 2007 at 11:54:14PM +0200, Oliver Brandmueller wrote: In sh: $ which rm /bin/rm $ cd /tmp $ mkdir -p foo/bar $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ pwd /tmp $ ktrace -i /bin/sh $ which rm /bin/rm $ mkdir -p foo/bar $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ rm -rf ../ $ ktrace -C ... 35356 rm NAMI ../ 35356 rm RET rmdir -1 errno 22 Invalid argument ... 35488 rm NAMI ../ 35488 rm RET lstat -1 errno 2 No such file or directory ... HTH, Patrick -- punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On 9/25/07, Oliver Fromme [EMAIL PROTECTED] wrote: Torfinn Ingolfsen wrote: Oliver Fromme wrote: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ rm -rf ../ $ [...] Quick testing here: [...] Ok, I think it is a bug. Yes, I think so, too. By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Maybe. But I expect that the behavior for rm -rf .. is there so that things don't get REALLY astonishing when you do rm -rf *. Having a different behavior for rm -rf ../ may have been intentional on someone's part so you can override the protection if you really want to. - Bob ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On Tue, 25 Sep 2007 17:55 +0100, jan.grant wrote: On Tue, 25 Sep 2007, Oliver Fromme wrote: Note that the command rm -rf ../ was entered twice. The first time I got an error message (and exit code 1), the second time it apparently succeeded. Check the man page for rm: -f Attempt to remove the files without prompting for confirma- tion, regardless of the file's permissions. If the file does not exist, do not display a diagnostic message or modify the exit status to reflect an error. That's what's happening the second time through. The first time, your current directory is getting removed (so ../ won't refer to a real directory the second time around). The bug is really in rm(1)'s initial diagnostic message. Just wanted to point out that this actually goes all the way back as far as 4.6.2-RELEASE-p27. I dont have any earlier machines than that to test on but best guess is that it most likely goes back further than that. -- - (2^(N-1)) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
