Good safeguards
In my last post I’ve shown that some people are annoyed at the fact that they can no longer erase their root directory simply by typing rm -rf /. I’m happy that this possibility is removed. I’m not scared that means Linux is being dumbed down. There are already some safeguards in Linux and nobody is complaining about them because they guard even seasoned users to do things that are dangerous or silly.
Proper safeguards
dpkg won’t remove itself
Erasing the primary package manager on your system prevents your from installing any other package. It is hard to argue that it is a good thing to let that happen without warnings.
fdgonthier@moka:~/ > sudo dpkg --purge dpkg dpkg: error processing dpkg (--purge): This is an essential package - it should not be removed. Errors were encountered while processing: dpkg
You can still erase dpkg if you want by using the --force-remove-essential option. I can actually think of reasons somebody might want to do that but this is a bad idea, and probably a mistake, most of the time its attempted. dpkg and apt protect essential and important packages on a Debian system by asking for obscure force options or confirmation, depending on what is attempted.
You can’t unmount /
fdgonthier@moka:~/ > sudo umount / umount: /: device is busy umount: /: device is busy
That is akin to removing the wheels of a running car. You can’t even force-unmount it.
You really shouldn’t fsck a drive in use
It is possible to do that, but when you call fsck.ext3 on a mounted partition, it will ask you with a rather serious prompt if you really want to proceed. fsck.ext3 has a force option but it has no effects on this prompt. This speaks volume about how much doing this is discouraged.
In good Unix fashion it is still possible to do it if you really want to but the developer of fsck.ext3 has made clear in the man page that you don’t want to do that.
Some kernel modules can’t be unloaded
modprobe has a force option (-f) too. It can be used to unload reluctant modules. It is clearly documented in modprobe manual page that removing by force may crash your system. I’ve used it a few times, it worked a few times, it crashed a few times, but most of the time it will not work if the module is important.
Why should it be possible to remove the module for the computer chipset while it is running? The answer is left to the imagination of the reader. I think its a good thing this kind of module won’t unload.
You can’t kill the init process
kill -9 1 will do nothing. This is actually hardcoded in the Linux kernel. The init process is the mother of all process in the system. Without it, you won’t be able to boot, or reboot, or use your virtual consoles. It is the reaper of zombies so if it dies, prepare for zombie invasion. There is really no reason to kill this process, ever.
You can’t format a mounted filesystem
fdgonthier@moka:~/ > sudo mkfs.ext3 /dev/sda1 mke2fs 1.41.5 (23-Apr-2009) /dev/sda1 is mounted; will not make a filesystem here!
mkfs.ext3 offers a way to force this but you have to use the force option (-F)twice.
Files in /dev are dynamically recreated
The health of your system is no longer tied to what is in the mysterious /dev directory. You can delete those files if you wan’t, and, depending what you erase, your currently running system may or may not be affected, but those problems will not survive a reboot or the invocation of /etc/init.d/udev restart.
GUI environment won’t let you in the dark
This is something common now. If for some reason, you change your resolution to something your monitor can’t support and your screen goes blank, desktop environment will automatically switch to your last used resolution. This is a safety mechanism preventing desktop users to set their screen to a resolution that leaves them without graphic display. Any resolution can still be configured statically into the system-wide xorg.conf if necessary.
Conclusion
All the safeguards and behaviors I’ve described above go against the Do What I Mean (DWIM) philosophy of Unix, and the something against the semantic of some option of the command: the kernel won’t let you unload your chipset module because it won’t work without it, mkfs.ext3 won’t let your format a partition that is in use because it’s certainly not what you want to do, dpkg won’t let your remove itself because there is a chance you won’t be able to reinstall it after it was removed.
If you think doing anything of what I’ve named above would be totaly stupid anyway, then you are right. Good safeguards aren’t there to nag you, and won’t ask you to double check everything you do. They simply prevent you from doing things that are possibly catastrophically detrimental to your system. Stop thinking rm -rf / should work because the Unix pilosophy about DYIM, because some command you can type have might no meaning at all.
Then a few things surprised me…
While testing potentially destructive commands in my test virtual machine, I’ve found I was able to do things I think I shouldn’t have. There might be some reason those things are possible. If you know why, please comment.
deluser: delete the root user
You can run deluser root as root without problems. This is of no consequences to the system because the root user is always the user with UID 0, but I think many scripts would be broken by that.
mkfs.ext3: tries to formats a directory
I don’t think a directory can hold a ext3 filesystem, yet mkfs.ext3 /etc will still try to proceed, and fail, after showing a warning telling that will probably won’t work.
fdgonthier@moka:~/ > sudo mkfs.ext3 /etc
[sudo] password for fdgonthier:
mke2fs 1.41.5 (23-Apr-2009)
/etc is not a block special device.
Proceed anyway? (y,n) y
mkfs.ext3: Device size reported to be zero. Invalid partition specified, or
partition table wasn't reread after running fdisk, due to
a modified partition being busy and in use. You may need to reboot
to re-read your partition table.
Should it even bother to try?
fdisk: delete an active, mounted partition
fsck.ext3 detects that if targeted partition is mounted. I don’t see why fdisk couldn’t do that. I think there is a good chance that deleting a mounted partition is a mistake and there is not even a warning before proceeding.
unmount /proc and /sys
Those pseudofilesystem have become necessary to a lot of program. It’s a bit weird that you can just unmount them without warnings.
More silly things…
cat /dev/urandom > /dev/mem will very quickly crashes your system. There are multiple variant to that, which are all as efficient as rm -rf / at causing harm to a Linux system.
Those silly commands are unlikely to outside forum of Linux users that love to abuse n00bs, so safeguarding against them is of little importance. Still, why should a superuser shell should have such a raw access to disk devices? Is it necessary? Is there a way to mitigate that?
If you like that post, please subscribe to my
RSS feed. More readers would motivate me to keep writing at least once a week.
[...] This entry now has a followup: Good safeguards. [...]
Arrogant Linux Elitists « lostwebsite.net blog
May 11, 2009 at 11:24 pm
If a disk is active (a partition is being used) when you use fdisk on it, the partition table is changed in the disk, but not in memory, so the changes will be seen on the next reboot. Which is probably what you want, when you modify a disk with / or /usr on it.
AFAIK, /proc and /sys are not really essential for a system (they are even optional, although recommended in the kernel configuration). And if they’re unmounted they’re trivial to remount.
And I would say yes, the access to raw devices is really necessary. As your example with /dev/mem, is not typical for a common user to even go near these files, but in a lot of situations, root (or some other user) needs to access these files directly (even for non-administrative tasks, like using some databases or sound applications).
Rodrigo B.
May 12, 2009 at 10:02 am
It just a bit weird to be able to delete a mounted partition. I think if you really mean to delete an active partition in use, fdisk should probably ask that you take the extra step of unmounting it before deleting it.
I think /sys, but especially /proc have become pretty much essential for a Linux desktop, but if they are missing things a lot of things will probably still work. Being able to unmount them is no big deal seeing how they will come back after a reboot, which is what a begginer will probably do if some process starts acting-up.
I don’t question the fact that access to raw device is necessary, but the fact that they can be written and read to using simple shell commands. This is an open question to which I have no answer.
fdgonthier
May 12, 2009 at 10:18 am
All I have to say is, there’s a reason people are told time and time again not to do stuff as root. Crippling userland applications is just about the worst solution when the problem in fact is that people don’t listen.
JosefA
May 12, 2009 at 1:36 pm
There is simply still too much things people can’t do without being root.
fdgonthier
May 12, 2009 at 1:38 pm
JosefA, I frequently have heard ‘Don’t do this or that as root! Never run as root!’. Unfortunately, somewhat obviously, you cannot run any of these commands at all as a non root user. Aptitude or modprobe are always going to be run as root, and therefore it makes sense to add some safeguards to their use as even experienced sysadmins can make mistakes.
Mario
May 12, 2009 at 1:42 pm
> kill -9 1 will do nothing. This is actually hardcoded in the Linux kernel. The init process is the mother of all process in the system.
Someone should tell Apple to do the same with our kernel. I read this and out of curiousity, did a `sudo killall launchd` (our process 1) and my macbook air shutdown and rebooted.
On to the rest of your post..
lowell
May 12, 2009 at 4:31 pm
[...] Good safeguards « lostwebsite.net blog (tags: linux tips) [...]
links for 2009-05-12 « My Weblog
May 13, 2009 at 12:05 am