|
Bugzilla – Full Text Bug Listing |
| Summary: | boot.crypto started too late | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Christian Boltz <suse-beta> |
| Component: | Basesystem | Assignee: | Dr. Werner Fink <werner> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | mrueckert |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Christian Boltz
2005-12-19 19:50:59 UTC
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 |