We had a “Senior Unix Admin” at a company I worked for who removed /vmunix because “we were low on disk space and that file hadn’t been touched in years.” That was a good time.
Does any one here remember the bug in Solaris 8 (I think the initial releases– it was certainly patched later), where rm did not leave out . and ..? As you would expect, rm -rf .* on any directory had amusing consequences!
ps: Having been bitten by it a few times, while testing our product, I know it existed, but I cant find the information on the bug any more. If any one remembers, I would be really glad!.
The shell expands it to “..”. It’s rm’s responsibility to skip “..”.
That said, while there have been rumors that this or that unix would delete “..”, the earliest sources I have available to me check for that case and ignore it. Other than systemd, I’m not aware of a system that actually had this bug. Solaris 8 would seem to be at least a decade too late.
Here’s a rather old copy of rm. As you can see, it checks for “..” and won’t remove it.
I did make this mistake recently with, I think chmod. I wanted to make root’s dot files and directories world inaccessible and proceeded to make the entire system starting with /root/.. more secure.
This was a bug later introduced, (from what I remember). Unfortunately, while I can access the OpenSolaris source, the history stops at the OpenSolaris launch. As you can see, by comparison to the rm.c from the unix-history-repo, the file has been refactored and reworked quite extensively.
Long ago, in UNIX V6, there was a program /etc/glob that would expand
wildcard patterns. Soon afterward this became a shell built-in.
These days there is also a library routine glob(3) that will perform
this function for a user program.
I don’t know if this played a role in the alleged bug.
FWIW, this was posted in 2015, albeit with a different URL. Earlier discussion.
We had a “Senior Unix Admin” at a company I worked for who removed
/vmunixbecause “we were low on disk space and that file hadn’t been touched in years.” That was a good time.I’ve never had that bad incident, but I remeber recovering one of our servers from
mv /* /tmp/or something similar.The solution is actually quite simple. Set up
LD_LIBRARY_PATH=/tmp/lib64and run/tmp/lib64/ld-linux-x86-64.so.2 /tmp/bin/mv /tmp/* /.I’ve never recovered the system I’ve un-
tared over while unlinking files first. :-)Does any one here remember the bug in Solaris 8 (I think the initial releases– it was certainly patched later), where
rmdid not leave out.and..? As you would expect,rm -rf .*on any directory had amusing consequences!ps: Having been bitten by it a few times, while testing our product, I know it existed, but I cant find the information on the bug any more. If any one remembers, I would be really glad!.
Shouldn’t it be the shell’s responsibility to expand the glob pattern
.*?The shell expands it to “..”. It’s rm’s responsibility to skip “..”.
That said, while there have been rumors that this or that unix would delete “..”, the earliest sources I have available to me check for that case and ignore it. Other than systemd, I’m not aware of a system that actually had this bug. Solaris 8 would seem to be at least a decade too late.
Here’s a rather old copy of rm. As you can see, it checks for “..” and won’t remove it.
https://github.com/dspinellis/unix-history-repo/blob/Research-V7-Snapshot-Development/usr/src/cmd/rm.c
I did make this mistake recently with, I think chmod. I wanted to make root’s dot files and directories world inaccessible and proceeded to make the entire system starting with /root/.. more secure.
EDIT: And probably group inaccessible.
This was a bug later introduced, (from what I remember). Unfortunately, while I can access the OpenSolaris source, the history stops at the OpenSolaris launch. As you can see, by comparison to the rm.c from the unix-history-repo, the file has been refactored and reworked quite extensively.
Yes it is.
From glob(7):
I don’t know if this played a role in the alleged bug.