[net.unix-wizards] VERY SERIOUS rmdir bug

john@basser.UUCP (07/17/86)

John Tupper pointed out an rm bug (that it didn't check properly
for pathnames ending in .. on recursive removes).  That got one of
our users here to experimenting, and he found that he could remove ..
from directories.  The amount of braindamage this sort of thing can
cause is large.  I believe that the bug will be likely to be found
on any machine that doesn't do rmdir by system call, although I haven't
checked sysV sources, not having any handy.

To demonstrate the bug, do this:

$ mkdir foo foo/bar
$ rmdir foo/bar/../bar
(rmdir will cough along the lines of "foo/bar/../bar not removed")
$ od -c foo/bar
(note the lack of a .. in bar.  get very sad.)

We have fixed rmdir, but I would like to wait a couple of days to
see if I can think of any more problems (or any bugs in the fix,
which wasn't simple) before posting a diff.

John Mackin, Basser Department of Computer Science,
	     University of Sydney, Sydney, Australia

{seismo,hplabs,mcvax,ukc,nttlab}!munnari!basser.oz!john
john@basser.oz.au (john%basser.oz@SEISMO.CSS.GOV)

dave@inset.UUCP (Dave Lukes) (07/22/86)

In article <707@basser.oz> john@basser.oz (John Mackin) writes:
>	...
>  I believe that the bug will be likely to be found
>on any machine that doesn't do rmdir by system call, although I haven't
>checked sysV sources, not having any handy.
>
>To demonstrate the bug, do this:
>
>$ mkdir foo foo/bar
>$ rmdir foo/bar/../bar
>(rmdir will cough along the lines of "foo/bar/../bar not removed")

I just tried this on our V.2 VAX and it does exactly the same thing (yawn) ....

This seems to be another variant on the:

	$ mkdir foo
	$ cd foo
	$ rmdir `pwd`

scenario which caused confusion on V7. 

>We have fixed rmdir, but I would like to wait a couple of days to
>see if I can think of any more problems (or any bugs in the fix,
>which wasn't simple) before posting a diff.

Good: give that fix a really HAAAAAARRRRRRRRD time.

What worries me is how many other hidden nasties are waiting in that nasty
little (~~100 lines) piece of code.
Well, at least we don't have symbolic links to confuse things even more.

	XXXXXX
-- 

		Dave Lukes. (...!inset!dave)

``Fox hunting: the unspeakable chasing the inedible'' -- Oscar Wilde

charles@c3pe.UUCP (07/29/86)

In article <1074@inset.UUCP> dave@inset.UUCP (Dave Lukes) writes:
}In article <707@basser.oz> john@basser.oz (John Mackin) writes:
}>To demonstrate the bug, do this:
}>
}>$ mkdir foo foo/bar
}>$ rmdir foo/bar/../bar
}>(rmdir will cough along the lines of "foo/bar/../bar not removed")
}
}What worries me is how many other hidden nasties are waiting in that nasty
}little (~~100 lines) piece of code.

What worries ME is the fact that our "fsck" doesn't even notice the missing
parent directory!  Isn't that one of the things "Check Connectivity" is for??
-- 
-Charles Green at C3 Inc.	{styx!seismo,cvl,dolqci}!decuac!c3pe!charles
	"Some try to tell me / Thoughts they cannot defend"    -The Moody Blues

marc@homer.UUCP (08/05/86)

>>To demonstrate the bug, do this:
>>
>>$ mkdir foo foo/bar
>>$ rmdir foo/bar/../bar
>>(rmdir will cough along the lines of "foo/bar/../bar not removed")
>
>This seems to be another variant on the:
>
>	$ mkdir foo
>	$ cd foo
>	$ rmdir `pwd`
>
>/* End of text from homer:net.unix-wizar */

try this one:
	$ mkdir foo
	$ cd foo
	$ (cd ..; rmdir foo)
then try
	$ pwd
	$ l
	$ cd ..

this is great fun!

-----

						marc brumlik

				 ...trsvax!hal6000!unify1!\
							   >homer!marc
					    ...ihnp4!sys1!/

latham@bsdpkh.UUCP (Ken Latham) (08/16/86)

In article <-932157@homer> marc@homer.UUCP writes:
>
>>>To demonstrate the bug, do this:
>>>
>>>$ mkdir foo foo/bar
>>>$ rmdir foo/bar/../bar
>>>(rmdir will cough along the lines of "foo/bar/../bar not removed")

THE ABOVE IS A REAL BUG ....
>>This seems to be another variant on the:
>>
>>	$ mkdir foo
>>	$ cd foo
>>	$ rmdir `pwd`
>>
>>/* End of text from homer:net.unix-wizar */
>
>try this one:
>	$ mkdir foo
>	$ cd foo
>	$ (cd ..; rmdir foo)
>then try
>	$ pwd
>	$ l
>	$ cd ..
>
>this is great fun!

..... NO it's SHELL !!!!

these two are "BUGS" in shell not 'RMDIR' ( not technically though )

When you remove the cwd from inside shell, you strand yourself there.
Ksh does not have these problems.



			Ken Latham, AT&T-IS (via AGS Inc.), Orlando , FL

			uucp: ihnp4!bsdpkh!latham

levy@ttrdc.UUCP (Daniel R. Levy) (08/20/86)

In article <236@bsdpkh.UUCP>, latham@bsdpkh.UUCP (Ken Latham) writes:
>>try this one:
>>	$ mkdir foo
>>	$ cd foo
>>	$ (cd ..; rmdir foo)
>>then try
>>	$ pwd
>>	$ l
>>	$ cd ..
>>
>>this is great fun!
>
>..... NO it's SHELL !!!!
>
>these two are "BUGS" in shell not 'RMDIR' ( not technically though )
>
>When you remove the cwd from inside shell, you strand yourself there.
>Ksh does not have these problems.
>			Ken Latham, AT&T-IS (via AGS Inc.), Orlando , FL

Not really.  In SysV or other /bin/sh you're not stranded; you can get out
by specifying a fully qualified pathname (e.g., cd /tmp or cd $HOME).  Also
in some (all?) BSD systems, "pwd" is not a Bourne shell builtin.

Besides, even in ksh, the ls and cd commands will fail miserably when used
relative to a directory you are in that has been removed.  Wouldn't it be
better for ksh 'pwd' and 'cd' to warn that the directory was gone, and for
'cd' to also attempt to work figuring that '..' should mean parent directory,
etc.?
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
	   go for it!  			allegra,ulysses,vax135}!ttrdc!levy

gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/23/86)

The BRL version of the SVR2 Bourne shell maintains an idea of the
current directory internally, and uses it when one tries a relative
"cd".  I set its idea of where I am initially by "cd $HOME" and
it never gets lost after that.  This is particulary important when
your file system is chock full of symbolic links to directories,
as ours is.  (Otherwise, "cd ..; rm -rf subdir" can be quite a
surprise when .. turns out to not be the place you just came from!)
Some people like this behavior, and some don't.  Now that I've tried
it for quite a while, I'm all for it.