Date: Wed, 14 Feb 96 21:51 WET From: uhclem@nemesis.lonestar.org (Frank Durda IV) To: hackers@freebsd.org Subject: Is "immutable" supposed to be a good idea? Message-ID: <m0tmuiw-000CU4C@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
I ran into a very annoying support call yesterday. A 2.1 system had crashed badly and had rebooted and fscked automatically, causing some key directories to be "lost" and some files to be corrupted. It may have actually rebooted several times before it could not proceed further. After wading through the debris, it became obvious that several of the shared libraries were corrupted and needed to be replaced. Almost none of the dynamically linked applications would run, or they would dump core immediately. Some of the /stand directory files were also missing, but "mt" and "restore" still worked, so I took the latest backup and used it to restore /usr/lib. But guess what I found once the restore was complete? Thanks to those lovely "immutable" flags on the shared libraries, the restore had no effect on them! So after the restore was completed, the garbled files were still there. Of course, /stand/rm would not work to get rid of these files, chflags wasn't around anymore (and it probably relies on the shared libraries anyway since it isn't in /stand). Finally, (thankfully) I realized I could "/stand/mv" the entire /usr/lib directory out of the way, delete all I could out of the copy, then restore /usr/lib from tape. Then I could get to fixing the rest of the damage with tools that worked. The result of this was that the immutable flags on the libraries extended the amount of time to recover the system by some hours. I noted some recent discussion about the "hole" created by being able to move a directory containing an immutable file elsewhere. Thank goodness for this "hole"! Don't plug it! I probably would have had to nuke the entire system otherwise. If restore isn't really doing a restore, then it would be Really Nice if it said so, something like "I can't replace this file", or "%d files could not be restored". Personally, if this immutable thing has to stay (of which currently I see no benefit except to prevent people running as root from doing stupid things and to prevent people running as root or in maintenance mode from doing smart things), I would rather see restore, tar, cpio, rm and any other system recovery tools all be able to replace files with these flags, if the utility is running suid==root. We should not make the system impossible to maintain or to recover. It would also be nice if a static version of chflags existed in /stand too, NOT A LINK. If this utility is so bloody important there ought to be a couple of copies of it around. Strangely, one of the directories with these immutable files was moved into /tmp to get it out of the way. On the next reboot, the normal system start was able to get rid of all of the files. That seems curious. What has rc got that I haven't got? Unless someone knows a really good reason, I plan to turn off immutable on all files on the customer systems I have to maintain. This was too big of a hassle to revisit and cost everybody involved. Oh, weird party trick: some time just before nuking a system to do a fresh install or something, rm /sbin/init, halt and reboot and watch. That is certainly not what other UNIX systems do... Frank Durda IV <uhclem@nemesis.lonestar.org>|"You are in a maze of twisty or uhclem%nemesis@rwsystr.nkn.net | little symlinks, all alike." ^------(this is the fastest route)| or ...letni!rwsys!nemesis!uhclem |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0tmuiw-000CU4C>