Bugzilla – Bug 140226
boot.crypto started too late
Last modified: 2007-01-29 14:18:19 UTC
I have an encrypted /home partition and also some directories (/tmp, most of /var/*) symlinked to this partition. At bootup, I see several messages that some scripts need /tmp: --------------------------------------------------------------- /etc/init.d/boot.preload_early: line 23: /var/cache/preload/boot.preload: No such file or directory failed mkdir: cannot create directory `/tmp': File exists mkdir: cannot create directory `/tmp/.X11-unix': No such file or directory mkdir: cannot create directory `/tmp/.ICE-unix': No such file or directory mkdir: cannot create directory `/var/tmp': File exists mkdir: cannot create directory `/var/tmp/vi.recover': No such file or directory Starting Firewall Initialization (phase 1 of 2) mktemp: cannot create temp file /tmp/SuSEfirewall2_iptables.LAcs2489: No such file or directory failed --------------------------------------------------------------- As you can see, boot.preload_early, a script creating several directories in /tmp and SuSEfirewall2 phase 1 fail because /tmp is a symlink to my (not yet mounted) /home partition. It would be a really good idea to start boot.crypto earlier ;-) I guess the best solution would be to run boot.crypto directly after mounting the unencrypted filesystems. If you need more information, just ask.
You can not start boot.crypto earlier. Do not use /var and /tmp as encrypted paritions. The dependcies of /etc/init.d/boot.crypto are defined within the LSB header in this file: ### BEGIN INIT INFO # Provides: boot.crypto # Required-Start: boot.localfs boot.klog # Should-Start: boot.md boot.lvm # Required-Stop: # Default-Start: B # Default-Stop: # Description: Enable crypto file systems before leaving boot phase ### END INIT INFO That mean that the localfs, which includes /var and /tmp, should be mounted.
(In reply to comment #1) > You can not start boot.crypto earlier. Is there a specific reason _why_ this can't be done? > Do not use /var and /tmp as encrypted paritions. Doing so, I can also stop using an encrypted /home - sooner or later parts of my data will appear in /tmp or /var/tmp *unencrypted* :-( From a security point of view (which should be consided if someone decides to use encrypted filesystems ;-) I highly recommend to encrypt /tmp and /var. If you don't think so, please give me a _good_ reason. > That mean that the localfs, which includes /var and /tmp, should > be mounted. Maybe, but it does not mean that you have to wait with boot.crypto some time after mounting the unencrypted partitions.
??? I've said that this is invalid. Encryption of /tmp and /var makes the system unusable because this partitions are used very heavily. Beside this boot.crypto waits on the passphrase and nothing more. Note, that reopening will not help. I'll close this or simply ignore it.
you could use $TMP and $TMPDIR to set a tmp path on your encrypted partition. if you want it for every user you can use pam_env for it.
Does every program and script honor $TMP or $TMPDIR? I guess no :-( - so this would still leave a (maybe smaller) security risk. Werner, > Encryption of /tmp and /var makes > the system unusable because this partitions are used very heavily. As I already said in my initial report, I have /tmp and /var encrypted (except /var/run, /var/lock and /var/log). I can tell you that my system is *very usable* ;-) - only the mentioned error messages appear, but I didn't notice that one of them caused real trouble. If boot.crypto would start directly after boot.localfs, even those error messages would go away. I just removed "boot.klog" from Required-Start to archive this. (Didn't test yet, but I don't expect any problems.) (Marcus, feel free to remove yourself from CC if you like. I just wanted to avoid you miss this comment ;-)
Hmmm ... AFAIK boot.localfs mounts all local partitions from /etc/fstab including /tmp and /var. If you're using /var/run, /var/lock and /var/log not from /var this is an exception because most user/sysadmins do not. The boot.klog dependcy was thought to be a help to see if something goes wrong with boot.crypto and to avoid kernel messages on the first virtual console destroying the prompt of boot.crypto. OK, I'm only the author of boot.crypto but I do not like such messages even as user of boot.crypto ;)
I found a solution that a) allows /tmp and large parts of /var (except /var/log, /var/lock and /var/run to be on an encrypted partition. Most important here: /tmp and /var/tmp can be encrypted b) does not print any kernel messages to the console (boot.klog is still started before boot.crypto) --- boot.cleanup_ORIG 2006-06-22 13:33:04.000000000 +0200 +++ boot.cleanup 2006-06-22 13:33:40.000000000 +0200 @@ -8,7 +8,7 @@ ### BEGIN INIT INFO # Provides: boot.cleanup # Required-Start: boot.localfs -# Should-Start: boot.quota +# Should-Start: boot.quota boot.crypto # Required-Stop: # Default-Start: B # Default-Stop: This results in the following boot order: S01boot.rootfsck S02boot.preload_early S02boot.proc S02setserial S03boot.udev S04boot.loadmodules S05boot.device-mapper S05boot.md S06boot.localfs <--- S07boot.clock S07boot.klog <--- S07boot.scpm S07boot.udev_retry S07boot.videobios S08boot.crypto <--- S09boot.cleanup S09boot.preload S09boot.swap S10boot.ldconfig S10boot.localnet S11boot.isapnp S11boot.sched S11SuSEfirewall2_init S12boot.ipconfig Since this fulfills the requirements of your comment #6, I'm reopening this bug. The only disadvantage I see is that boot.preload does not run in parallel while waiting for the password - but security always has a price ;-) If you don't like my solution nevertheless, feel free to close this bug as "wontfix" again.
Another one that needs /tmp is boot.apparmor: --- boot.apparmor_orig 2006-08-19 21:49:57.000000000 +0200 +++ boot.apparmor 2006-08-19 21:50:43.000000000 +0200 @@ -32,6 +32,7 @@ ### BEGIN INIT INFO # Provides: apparmor # Required-Start: boot.localfs +# Should-Start: boot.crypto # Default-Start: B 2 3 5 # Default-Stop: # Short-Description: AppArmor initialization
should be fixed now