[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[Noel Chiappa]

    > From: "Ron Natalie"

    > Actually, it's the shell that calls glob.

Yes, in the initial expansion of the command line, but V6 'rm' also uses
'glob' internally; if the '-r' flag is given, and the current name in the
command argument list is a directory, viz.:

	if ((buf->mode & 060000) == 040000) {
		if (rflg) {
			...
			execl("/etc/glob", "glob", "rm", "-r", 
					    fflg? "-f": "*", fflg? "*": p, 0);
			printf("%s: no glob\n", arg);
			exit();
			}			

(where 'p' is 0 - no idea why the writer didn't just say '"*": 0, 0').

So "rm -f foo*", where the current directory contains file 'foo0 foo1 foo2'
and directoty 'foobar', and directory 'foobar' contains 'bar0 bar1 bar2', the
first instance of 'glob' (run by the shell) expands the 'foo0 foo1 foo2 foobar'
and the second instance (run by 'rm') expands the 'bar0 bar1 bar2'.


     > Glob then invokes the command (in this case rm).

I don't totally grok 'glob', but it is prepared to exec() either the command
name, /bin/{command} or /usr/bin/{command}; but if that file is not executable
it tries feeding it to the shell, on the assumption it must be a shell command
list:
	   
	execv(file, arg);
	if (errno==ENOEXEC) {
		arg[0] = file;
		*--arg = "/bin/sh";
		execv(*arg, arg);
		}

I guess (too lazy to look) that the execv() must return a different error
number if the file doesn't exist at all, so it only tries the shell if the
file existed, but wasn't executable.

	Noel

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[Noel Chiappa]

    > From: Kurt H Maier

    > /etc/glob, which appears to report no-match if the first character is .

So I couldn't be bothered to work out how 'glob' worked exactly, so I just did
an experiment: I created a hacked version of 'rm' that had the directory
handling call to glob call 'echo' instead of 'rm'; it also printed 'tried'
instead of the actual unlink call, and printed 'cd' when it changed
directories.

I then set up two subsidiary directors, foo and .bar, with one containing
'.foo0 foo1' and the other '.bar0 bar1'.

Saying 'xrm -r -f .*' produced this:

  cd: .
  -r -f foo xrm xrm.c
  cd: ..
  -r -f foo xrm xrm.c
  cd: .bar
  -r -f bar1 

(This system has /tmp on a mounted file system, which is why the 'cd ..' was a
NOP. And a very good thing, too; at one point the phone rang, and it
distracted me, and I automatically typed 'rm', not 'xrm'... see below for what
happened. No biggie, there were only my test files there.  The output lines
are "-r -f foo xrm xrm.c" because that's what 'glob' passed to 'echo'.)

Saying 'xrm -r -f *' produced this:

  cd: foo
  -r -f foo1
  xrm: tried
  xrm.c: tried     

So apparently 'glob', when presented with '*' , ignores entries starting with
'.', but '.*' does not.


When I stupidly typed 'rm -r -f .*', it did more or les what I originally
thought it would: deleted all the files in all the directories (but only on
the /tmp device, because .. linked to the itself in /tmp, so it didn't escape
from that volume); leaving all the directories, but empty, except for the
files .foo0 and .bar0. So files and inferior directories with names starting
with '.' would have escaped, but nothing else.

	Noel

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[ron minnich]

On Mon, Apr 24, 2017 at 5:24 PM Kurt H Maier <khm at sciops.net> wrote:

>
>
>
> They committed a patch to fix it.  The project maintainer declared it a
> non-problem ex post facto and met with some derision... but by that
> point they at least had a safeguard in place.
>
> khm
>

ah, good to know.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170425/d396e26a/attachment.html>

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[Kurt H Maier]

On Tue, Apr 25, 2017 at 12:22:44AM +0000, ron minnich wrote:
> On Mon, Apr 24, 2017 at 5:18 PM Kurt H Maier <khm at sciops.net> wrote:
> 
> >
> >
> > And systemd is now catching up.  "Those who do not study unix" etc
> >
> >
> 
> not catching up, as I read the discussion it is marked as "working as
> intended".


They committed a patch to fix it.  The project maintainer declared it a
non-problem ex post facto and met with some derision... but by that
point they at least had a safeguard in place.

khm

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[ron minnich]

On Mon, Apr 24, 2017 at 5:18 PM Kurt H Maier <khm at sciops.net> wrote:

>
>
> And systemd is now catching up.  "Those who do not study unix" etc
>
>

not catching up, as I read the discussion it is marked as "working as
intended".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170425/5158ef09/attachment.html>

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[Kurt H Maier]

On Mon, Apr 24, 2017 at 08:06:28PM -0400, Ron Natalie wrote:
> 
> 
> > rm in V6 outsources globbing to /etc/glob, which appears to report
> > no-match if the first character is .
> 
> Actually, it's the shell that calls glob.   Glob then invokes the command
> (in this case rm).
> 
> Anyhow, that doesn't do what you think it does.    It ignores directory
> entries that begin with '.' if the search string doesn't begin with ..
> 
> ".*"  will indeed match ".."
> 
> Of course, the calamity depends on whether you have /tmp on it's own
> filesystem.   V6 didn't go .. off the top of the filesystem, the root ..
> just linked back to the inode 1 (the root itself).
> 
> 

Thanks for correcting my hasty conclusions.  /usr/source/s2/rm.c has an
execl call in the rm() function, but I didn't dig further into the
calling mechanism.  

V7's /usr/src/cmd/rm.c definitely explicitly has a check for '..' and 
an error message dedicated to the task.  

So I think we can conclude that unix got this protection sometime
between V6 and V7 -- in other words, sometime in the late 1970s. 

And systemd is now catching up.  "Those who do not study unix" etc

khm

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[Ron Natalie]

> rm in V6 outsources globbing to /etc/glob, which appears to report
> no-match if the first character is .

Actually, it's the shell that calls glob.   Glob then invokes the command
(in this case rm).

Anyhow, that doesn't do what you think it does.    It ignores directory
entries that begin with '.' if the search string doesn't begin with ..

".*"  will indeed match ".."

Of course, the calamity depends on whether you have /tmp on it's own
filesystem.   V6 didn't go .. off the top of the filesystem, the root ..
just linked back to the inode 1 (the root itself).

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[Kurt H Maier]

On Tue, Apr 25, 2017 at 12:18:41AM +0200, Josh Good wrote:
> On 2017 Apr 24, 18:06, Noel Chiappa wrote:
> >     > From: Josh Good
> > 
> >     > Would the command "cd /tmp ; rm -rf .*" be able to kill a V6 ... system?
> > 
> > So, assuming one did that, _and_ (important caveat!) _performed that command
> > as root_, it probably would empty out the entire directory tree. (I checked,
> > and "cd /tmp ; echo .*" evaluates to ". .." on V6.
> 
> Yeah, but does "rm" in V6 has a built-in "brake" to not process "." nor
> "..", no matter what ("-f")?
> 
> -- 
> Josh Good
> 

rm in V6 outsources globbing to /etc/glob, which appears to report
no-match if the first character is .
       
https://github.com/dspinellis/unix-history-repo/blob/Research-V6-Snapshot-Development/usr/source/s1/glob.c#L151
       
khm

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[Josh Good]

On 2017 Apr 24, 18:06, Noel Chiappa wrote:
>     > From: Josh Good
> 
>     > Would the command "cd /tmp ; rm -rf .*" be able to kill a V6 ... system?
> 
> So, assuming one did that, _and_ (important caveat!) _performed that command
> as root_, it probably would empty out the entire directory tree. (I checked,
> and "cd /tmp ; echo .*" evaluates to ". .." on V6.

Yeah, but does "rm" in V6 has a built-in "brake" to not process "." nor
"..", no matter what ("-f")?

-- 
Josh Good

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[Kurt H Maier]

On Mon, Apr 24, 2017 at 11:42:14PM +0200, Josh Good wrote:
>
> So, to get on-topic, I have a question for UNIX historians: when was it
> first defined in the UNIX realm that "rm -r .*" should NOT delete the
> current and parent directories? Would the command "cd /tmp ; rm -rf .*"
> be able to kill a V6 or V7 UNIX system?
       
       
V7 has a dotname function it uses to protect against this.
       
khm

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[Noel Chiappa]

    > From: Josh Good

    > Would the command "cd /tmp ; rm -rf .*" be able to kill a V6 ... system?

Looking at the vanilla 'rm' source for V6, it cannot/does not delete
directories; one has to use the special 'rmdir' command for that. But,
somewhat to my surprise, it does support both the '-r' and '-f' flags, which I
thought were later. (Although not as 'stacked' flags, so you'd have to say
'rm -r -f'.)

So, assuming one did that, _and_ (important caveat!) _performed that command
as root_, it probably would empty out the entire directory tree. (I checked,
and "cd /tmp ; echo .*" evaluates to ". .." on V6.

	Noel

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[Arthur Krewat]

Having done exactly this with one of my own systems back in the early 
90's, I decided to test this out - I have some Solaris 8 VM's that I was 
able to clone easily and rip off the networking.

kilowatt# mkdir a
kilowatt# cd a
kilowatt# touch .a .b .c
kilowatt# rm -rf .*
kilowatt# ls -a
.   ..
kilowatt# rm -rf .*
rm of . is not allowed
rm of .. is not allowed

Now I need to go check some of the other VM's I have of early SVR4... I 
think it was either SunOS or an early SVR4 where this had catastrophic 
results :)





On 4/24/2017 5:48 PM, Alec Muffett wrote:
> Off-topic but funny: I have personally witnessed a 4.1BSD Vax where 
> someone accidentally did "mv . .." (or possibly "mv .. .") and it 
> worked, with resulting horrible mess.
>
>   -a
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170424/3d2f4e08/attachment.html>

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[Alec Muffett]

Off-topic but funny: I have personally witnessed a 4.1BSD Vax where someone
accidentally did "mv . .." (or possibly "mv .. .") and it worked, with
resulting horrible mess.

    -a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170424/742c06be/attachment.html>

[TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

[Josh Good]

Hello all.

It's off-topic for this list, but there is turmoil in Linux-land. A bug
was discovered in systemd, whereby systemd re-implemented "rm"
functionality without following POSIX "rm" behaviour. This could kill a
system, as explained here: https://github.com/systemd/systemd/issues/5644

The reference POSIX "rm" behaviour is that "rm -rf .*" should NOT delete
the current and parent directories, as stated here:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html#tag_20_111_16

So, to get on-topic, I have a question for UNIX historians: when was it
first defined in the UNIX realm that "rm -r .*" should NOT delete the
current and parent directories? Would the command "cd /tmp ; rm -rf .*"
be able to kill a V6 or V7 UNIX system?

Regards,

-- 
Josh Good