Upstart doesn't activate luks volumes (also non luks) in cryptsetup
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cryptsetup (Ubuntu) |
Fix Released
|
High
|
Reinhard Tartler | ||
loop-aes-utils (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
usplash (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
My laptop's home is a LUKS encrypted volume that's listed in crypttab to be mapped to /dev/mapper/home which worked wonderfully in dapper (i.e. boot interrupted, asked for pw, continued), in edgy however boot freezes, after a while the splash goes away, I get to single user and fsck complains about not being able to check /dev/mapper/home (which is in fstab) because the LUKS volume was not activated. Activating the volume by hand lets the boot process continue.
Scott James Remnant (Canonical) (canonical-scott) wrote : | #1 |
Changed in upstart: | |
status: | Unconfirmed → Rejected |
Dennis Austmann (daustmann) wrote : | #2 |
Same problem here, encrypted volumes not mapped. I could see cryptsetup messages briefly flowing by during boot, so it really looks like upstart calls cryptsetup to map these volumes.
Scott James Remnant (Canonical) (canonical-scott) wrote : | #3 |
sysv-rc calls cryptsetup, as it iterates /etc/rc?.d
Gabriel Ambuehl (gabriel-ambuehl) wrote : | #4 |
Is cryptsetup perhaps being loaded and sent to the background detached from the console? If I boot the kernel without splash I see it complaining about not being able to read the password. It definitely needs to be run interactively.
Scott James Remnant (Canonical) (canonical-scott) wrote : | #5 |
It's loaded detached from the console, which is why it has code at the top of the cryptsetup.
Unfortunately it appears that it may also need that to be its "controlling tty"
Projekt (projekte) wrote : | #6 |
Same problem here. I get this message two times before it tries to mount my partition:
> Enter LUKS passphrase: Command failed: error reading passphrase
Init/upstart offers me to enter root-pw to login, but even with this login I get the same error. After boot is completed I can log into a console and start cryptsetup.
Is there any workaround yet? It annoys me to log into a console and restart /etc/init.
naheed (naheed) wrote : | #7 |
Quite annoying bug each time you boot the system.
anwe (wegener) wrote : | #8 |
no news on this?
imho we are talking about a very important feature ...
Norm Walsh (ndw) wrote : | #9 |
I can confirm the behavior as well, FWIW. And it is certainly annoying...
Norm Walsh (ndw) wrote : | #10 |
Also FWIW, this is probably the same issue as bug #56319.
Reinhard Tartler (siretart) wrote : | #11 |
this bug is reproducible. Importance high, because this is a regression from previous ubuntu releases. Before, with sysvinit, it was possible to have filesystems like /home mounted at boot-time.
Changed in cryptsetup: | |
importance: | Undecided → High |
status: | Unconfirmed → Confirmed |
Scott James Remnant (Canonical) (canonical-scott) wrote : | #12 |
Note that this is also a universe package, so it's very low priority for main developers.
The problem appears to be that whatever asks for the password does so from /dev/tty, which isn't openable.
Reinhard Tartler (siretart) wrote : | #13 |
any progress on this? can we target this for edgy?
Norm Walsh (ndw) wrote : | #14 |
Ok. What is the supported mechanism for reading user input during the boot process? I'm happy to attempt a patch.
Matthias Hilbig (hilbig) wrote : | #15 |
An alternative to reading the password from console might be to use pam_mount, to mount the encrypted filesystem when the user logs in.
Here is a description of using pam_mount together with dmcrypt:
http://
Norm Walsh (ndw) wrote : | #16 |
Yes, if it was just the home directory, that would be a possibility. But I also encrypt a partition that daemons (e.g., Apache) need, so it's not really practical to postpone it all to login time.
With respect, it seems to me that even if cryptdisk is in Universe, this is a pretty substantial regression.
If upstart really can't be tuned to support this, I'd be hard pressed to support upstart (not that anyone's really going to make any decisions based on what I would support, of course).
Scott James Remnant (Canonical) (canonical-scott) wrote : | #17 |
This has absolutely nothing to do with upstart.
This bug is caused by the decision to not have standard input or output available to boot scripts by default.
If we still used sysvinit, the same bug would be present
Scott James Remnant (Canonical) (canonical-scott) wrote : | #18 |
I have a proposed fix for this, could somebody who uses cryptsetup try this...
Edit the init.d script, at the top you'll find some code that looks like:
stdin=`readlink /proc/self/fd/0`
if [ "${stdin#
exec </dev/console >/dev/console 2>&1
fi
Modify that so it reads:
stdin=`readlink /proc/self/fd/0`
if [ "${stdin#
exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` $0 "$@"
fi
jott (ottjochen) wrote : Re: [Bug 62751] Re: Upstart doesn't activate luks volumes in cryptsetup | #19 |
The patch works somehow, in the sense that it is now possible to enter
something. But
* the boot process continues, so that the graphical system pops up
before it is possible to enter the complete passphrase. Particularly,
mountall.sh is executed (and the crypted partitions are not mounted...).
* the passphrase is shown as it is typed.
Scott James Remnant (Canonical) (canonical-scott) wrote : Re: Upstart doesn't activate luks volumes in cryptsetup | #20 |
The alternate fix is to add "console owner" to /etc/event.d/rcS and /etc/event.d/rc2
Scott James Remnant (Canonical) (canonical-scott) wrote : | #21 |
Oh, add "-w" to the openvt call
jott (ottjochen) wrote : Re: [Bug 62751] Re: Upstart doesn't activate luks volumes in cryptsetup | #22 |
For me, both patches work, but the passphrase is still displayed (which
was never the case before...)
Reinhard Tartler (siretart) wrote : Re: Upstart doesn't activate luks volumes in cryptsetup | #23 |
I can confirm jott's observations.
When using cryptsetup on the shell (manually), the password is hidden. When used via the init script, the passphrase is shown in plaintext!
Norm Walsh (ndw) wrote : | #24 |
Oddly, I can't confirm those observations. The patches work for me and the password is not displayed when used via init. Very odd. I saw that upstart was updated recently, maybe that changed something?
Matthias Hilbig (hilbig) wrote : | #25 |
The init script fix works for me too. When I started ubuntu with the kernel parameters quiet and splash, the password was visible on the console. When I removed quiet and splash the password was not visible.
Reinhard Tartler (siretart) wrote : | #26 |
I can confirm that removing 'splash' from the boot options, together with scott's patch solves the problem for me.
I'm not sure what this has to do with usplash, but I created a bugtask for it and leave it unconfirmed.
Reinhard Tartler (siretart) wrote : | #27 |
- prepared upload Edit (2.7 KiB, text/plain)
I prepared a new upload with the fixes and workarounds so far.
I had to disable translations because of an unsubstituted MKINSTALLDIRS variable in Makefiles. Debian's cryptsetup pakage doesn't run automake at build time, and we have probably no time left to investigate that issue, so better release a package which doesn't FTBFS and has the workarounds for making this package usable.
Hamish Downer (mishd) wrote : | #28 |
The fix worked for me :)
As a possible improvement to the code, to include the old option (ie "ON_VT" == "yes" )
stdin=`readlink /proc/self/fd/0`
if [ "${stdin#
if [ "$ON_VT" != "yes" ]; then
exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` $0 "$@"
else
exec </dev/console >/dev/console 2>&1
fi
fi
Hamish Downer (mishd) wrote : | #29 |
Oh and I had to do a little searching for the file (as no one seems to mention it in the text above). The fix should be applied to
/lib/cryptsetup
(I'm not familiar with patch, so after a little blundering around failing to get it to work I went for the direct edit).
loko (arph) wrote : | #30 |
I did what mish says above, but for me the fix don't work.
i get a command prompt, with this:
Enter Password: Enter Password: there must be a error, cause it seems that the second "Enter Password" is inserted automaticaly.when i then try to enter my real password (plaintext) i get an error about a wrong password and mounting it later manually fails with something that says cannot read keyfile or so.
loko (arph) wrote : | #31 |
according to a tip from somebody, i forgot to change the line:
exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` $0 "$@"
to
exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` -w $0 "$@"
Now it works, but in plaintext like some other users posted before.
maybe this can be changed in the near future.
Zak Kipling (zak-k) wrote : | #32 |
I'm using loop-aes for encryption, and experiencing similar issues when /etc/init.
Adding "console owner" to /etc/event.d/rcS fixed that, but I also found that the password was echoed to the screen unless I removed "splash" from the boot command line.
Instead, I added the following to do_start() in /etc/init.
local stdin=`readlink /proc/self/fd/0`
if [ "${stdin#
fi
This seems to work correctly with or without "splash". Note that I found "openvt -s -w" to work better than "openvt -w -f -c `fgconsole`" in that regard -- ie switching to a new console rather than using the current one (which splash is potentially interfering with).
The ON_VT part doesn't seem to be necessary, since once we're running on a VT, stdin will be /dev/tty<something> and the "if" block will be skipped anyway.
Another point to note is that /usr might not be mounted yet when these scripts run, if it's not part of the root fs -- in which case openvt won't be available.
Christoffer Kjølbæk (ostehamster) wrote : | #33 |
Isn't this a problem with cryptsetup? I have a setup where a partition on my harddrive is encrypted with a key. This key is saved in a file, encrypted with openssl. Then I use pam_mount to mount it, whenever I log in.
I have this on two laptops, so when the first laptop was reinstalled with Edgy, I found out that I couldn't mount the encryptet system anymore. Cryptsetup didn't complain, but mount couldn't find the ext3 filesystem that should be on the device. I made a new encrypted partition using cryptsetup, which works just fine.
When I came to installing edgy on the other laptop, I wrote this info down:
1. The unencrypted key
2. The first ten lines from a hexdump of the encrypted partition
3. The first ten lines from a hexdump of the unencrypted partition “mounted” on /dev/mapper/
After installation of Edgy and cryptsetup, I did the same as above:
1. The unencrypted key was the same, which must indicate that openssl works like in Dapper
2. The first ten hexdump lines of the encrypted partition was the same, so the partition might not have changed (I should have made a MD5SUM of the entire partition, but I am quite sure it is unchanged.)
3. Then I made a hexdump of /dev/mapper/
I might be wrong, but I can’t see what else should cause this?
Regards
Christoffer
(By the way, this is how I have made my setup: http://
seldon7 (ubuntu-pengo) wrote : | #34 |
hey - i've got a workaround that I use, but not a fix.
ive set up an encrypted partition on /dev/hdb3
to get it to ask for the password when gnome loads up (and mount it then), ive taken the reference to it out of /etc/fstab, and included it into /etc/pmount.allow
then in the gnome startup programs (preferences>
gnome-terminal -e "pmount /dev/hdb3"
so the LUKS password prompt shows up each time gnome starts, and mounts the disk. i prefer this anyway to a password prompt half way through boot up.
not a fix, though, but it might help someone.
Jari Kankaala (jari-kankaala) wrote : | #35 |
Hi,
I'm also trying to get encryption to work under Edgy Eft. The tip given above seems to work, but after entering the LUKS password I get dumped into a root shell. I can exit and everything seems to continue as normal. Is there anyway to avoid getting into the root shell?
The tip I followed (I put this into /lib/cryptsetup
stdin=`readlink /proc/self/fd/0`
if [ "${stdin#
exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` -w $0 "$@"
fi
Jari Kankaala (jari-kankaala) wrote : | #36 |
Hmmm, this only seems to be true when I boot with an image created by "yaird". The Ubuntu one works fine. Sorry guys. I'm trying to follow this but I'm adapting it to Ubuntu:
http://
Swen Thümmler (swen-thuemmler) wrote : | #37 |
- Patch for /usr/share/initramfs-tools/scripts/local-top/cryptroot Edit (623 bytes, text/plain)
I have solved this issue for my crypted root filesystem by making the following modification to /usr/share/
--- cryptroot.orig 2006-11-12 12:31:08.000000000 +0100
+++ cryptroot 2006-11-12 12:30:41.000000000 +0100
@@ -160,7 +160,11 @@
# Loop until we have a satisfactory password
while [ 1 ]; do
- if [ -x "/sbin/cryptgetpw" ]; then
+ if [ -x "/sbin/
+ /sbin/usplash_write "INPUTQUIET Password:"
+ $cryptcreate < /dev/.initramfs
+ /sbin/usplash_write "CLEAR"
+ elif [ -x "/sbin/cryptgetpw" ]; then
else
This works for me (in the 2 tests I have made :-)).
Hope this helps.
--Swen
Jari Kankaala (jari-kankaala) wrote : | #38 |
Vielen Dank Swen!
Together with the modifications of /lib/cryptsetup
//Jari
Paul Sladen (sladen) wrote : | #39 |
Keybuk: is Swen's patch above the Right Thing To Do(tm)?
Ondřej Nový (onovy) wrote : | #40 |
hi, i have same problem. i have /crypt mounted as encrypted partition. I'm using passphrase. i don't' have root partition encrypted so swen's patch doesn't fix my problem :( - it's only for crypt root partition.
Reinhard Tartler (siretart) wrote : | #41 |
cryptsetup (2:1.0.4-8ubuntu1) feisty; urgency=low
* merge debian changes, remaining patches:
- Always output and read from the console. Ubuntu: #58794.
* other changes have been merged or do noy apply anymore
* read password via usplash if available in initramfs for rootfs. based on a patch from
Swen Thümmler (Thanks for that!) Ubuntu #62751
* read password from initscript via usplash if running. should fix the
rest of Ubuntu #62751. Only problem with that patch: It asks only once
for the password! improvements welcome!
Changed in cryptsetup: | |
assignee: | nobody → siretart |
status: | Confirmed → Fix Committed |
Marc Schiffbauer (mschiff) wrote : | #42 |
- /home/mschiff/tmp/cryptdisks.functions.patch Edit (1.1 KiB, text/plain)
Here is a patch that fixes the problem of only asking for the password one time.
One thing remaining where I currently do not know where its coming from (or if its related to that script):
Booting ends with a blank screen. Then I presh a key, then see the console login prompt, then can press Alt+F7 to switch to kdm/gdm.
-Marc
Changed in usplash: | |
status: | Unconfirmed → Rejected |
Reinhard Tartler (siretart) wrote : | #43 |
This bug is partly fixed now, still pending is the patch proposed by Marc Schiffbauer.
Changed in cryptsetup: | |
status: | Fix Committed → In Progress |
Ondřej Nový (onovy) wrote : | #44 |
and this problem is maybe fixed only in feisty+1 not in edgy.
Has anyone tested that fixes on non-root crypto partition?
for example /home mounted with cryptsetup init.d script (not initrd).
Gabriel Ambuehl (gabriel-ambuehl) wrote : Re: [Bug 62751] Re: Upstart doesn't activate luks volumes in cryptsetup | #45 |
> and this problem is maybe fixed only in feisty+1 not in edgy.
That essentially means Ubuntu is useless for anyone having sensitive data on
his laptop!
> Has anyone tested that fixes on non-root crypto partition?
> for example /home mounted with cryptsetup init.d script (not initrd).
The patches against the functions script don't work for me with /home in
crypttab.
Matthias Hilbig (hilbig) wrote : Re: Upstart doesn't activate luks volumes in cryptsetup | #46 |
I used the fix from Scott James and the patch from Marc Schiffbauer on a new edgy install with encrypted home partition. Everything works as expected:
- with usplash I get asked for the password via usplash
- without usplash I get asked for the password on the console
I do not get a blank screen when booting ends.
Matthias Hilbig (hilbig) wrote : | #47 |
- Patch from Scott James, Swen Thümmler and Marc Schiffbauer together Edit (1.1 KiB, text/plain)
I made one patch from the different patches in this bug for the file /lib/cryptsetup
usplash und console mode.
Gabriel Ambuehl (gabriel-ambuehl) wrote : Re: [Bug 62751] Re: Upstart doesn't activate luks volumes in cryptsetup | #48 |
> I made one patch from the different patches in this bug for the file
> /lib/cryptsetup
> console mode.
Thanks, that works for me just fine in console mode (I reinstalled cryptsetup
and then applied the patch).
With splash I get asked for the password but X doesnt properly come up anymore
after that (blackscreen). That is using a Nvidia GeForce Go5200 with Nvidia
Binary driver rel. 9629.
Reinhard Tartler (siretart) wrote : | #49 |
Matthias Hilbig <email address hidden> writes:
> I used the fix from Scott James and the patch from Marc Schiffbauer on
> a new edgy install with encrypted home partition. Everything works as
> expected I do not get a blank screen when booting ends.
Thank you for your feedback. I'll see that I prepare another upload with
the final patch for feisty and edgy-proposed, so that we can get this
fix into edgy.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Marc Schiffbauer (mschiff) wrote : Re: Upstart doesn't activate luks volumes in cryptsetup | #50 |
- latest patch with RC-code checking fix Edit (1.1 KiB, text/plain)
I just discovered one minor bug in my patch: the returncode-check is somewhat useless now as it would check only the rc of the last usplash_write command in case we have usplash running.
Here is an updated patch. (This patch is against the 1.0.4-8ubuntu1 package from feisty that I backported to edgy...)
I tested it on edgy with usplash enabled and usplash disabled, with correct passphrase and three times wrong passphrase entered.
What looks a bit odd: entering the wrong passphrase three times with usplash prints out many asterisks... and while entering the passphrase there are no asterisks shown.. so I guess this is an issue with usplash itself.
For John Doe user it might be good if he sees those while typing the passphrase. Somewhat cosmetic, but for the records.
-Marc
Marc Schiffbauer (mschiff) wrote : | #51 |
- latest patch with RC-code checking fix Edit (1.1 KiB, text/plain)
Sorry guys. Another update. This one fixes a potential syntax error in case with type the correct passphrase with usplash. (RC got not set in that case)
-Marc
Gabriel Ambuehl (gabriel-ambuehl) wrote : | #52 |
Marc: your patch doesn't apply cleanly (on Edgy) for me:
sudo patch -p0 < cryptdisks.
patching file /lib/cryptsetup
Hunk #1 FAILED at 265.
1 out of 1 hunk FAILED -- saving rejects to file /lib/cryptsetup
Marc Schiffbauer (mschiff) wrote : | #53 |
- cryptdisks.functions patch for edgy Edit (13.9 KiB, text/plain)
As I mentioned here [1] this patch was for the latest feisty version of the package.
The diff against the original edgy script is mich bigger because there changed some other things, too.
So for your convenience here is the patch against the current edgy version. I guess it will work, but its not tested (because I tested with a backported feisty version, which worked well)
-Marc
[1]: https:/
Stefan Daniel Schwarz (Wolfram Ravenwolf) (stefandanielschwarz) wrote : | #54 |
Marc: "and while entering the passphrase there are no asterisks shown. [...] For John Doe user it might be good if he sees those while typing the passphrase. Somewhat cosmetic, but for the records."
I'd rather not see asterisks when entering my passphrase because once an attacker knows how many characters are within the passphrase, the passphrase becomes a lot weaker and easier to crack. Instead of brute-forcing an unknown number of characters, one would only need to brute-force a known number of characters, drastically reducing the number of possibilities. For a regular password, this might not be of such concern, but a high-security passphrase should be kept as secure as possible. When entering the password in the console, it's not displayed, so I think when entering it at boot-up time it shouldn't be shown, either. Or even better, making it an option, perhaps set in /etc/default/
Gabriel Ambuehl (gabriel-ambuehl) wrote : Re: [Bug 62751] Re: Upstart doesn't activate luks volumes in cryptsetup | #55 |
Marc: Your patch now applies, but I still can't load X when using splash. I
don't care too much for splash (in fact I usually deactivate it to see better
what's going on) but some might care more than I do....
I agree with Stefan, no asteriskes is safer. Besides, it's very much standard
in most CLI!
Jari Kankaala (jari-kankaala) wrote : Re: Upstart doesn't activate luks volumes in cryptsetup | #56 |
Just did a fresh install of Edgy Eft and found to my delight that the mounting of encrypted volumes now works without any patching. It stops and asks repeatedly for a passphrase. There is only a small problem, LVM tries to mount before the encrypted volumes. If I enter the passphrase, continue the boot, login and manually start LVM then it works fine. Guess it's only a matter of changing the order in which services get started. Not sure how I should do it correctly myself but maybe someone knowledgeable can do it, or show me how it's done.
Jari Kankaala (jari-kankaala) wrote : | #57 |
Tried an easy, dirty fix today. Simply did:
sudo cp -s /etc/rcS.d/S26lvm /etc/rcS.d/S29lvm
Which just creates a symbolic link so it runs lvm again after setting up the cryptdisks. Seems to work. Had some problems when just moving S28cryptdisks in front of lvm.
Franz Dietrich (franz-die) wrote : | #58 |
Ok
I upgraded my system to ubuntu 6.10 then cryptodisk wasn't working anymore - I found the edgy patch and patched my system.
(sudo patch -p0 <cryptdisks.
but after that i can't start cryptodisk anymore. not even manually.
every time I trie to it says "starting cryptodisk"... but it doesn't ask for any passphrase consequently it doesn't mount anything.
what was wrong or how can I undo the patch?
khymon (dennismail) wrote : | #59 |
I am facing the same problem. Is the fix already included in new install cd? If not, when will this be done?
khymon (dennismail) wrote : | #60 |
It is not yet included. As I am quite new to this subject, it would be nice to give me a real step for step instruction what to do exactly after a new edgy installation! Thanks in advance!
khymon (dennismail) wrote : | #61 |
- Packages changed at first edgy update process Edit (1.7 KiB, text/plain)
Okay, I found out some important things. What I did is to reinstall dapper, activate all repositories in /etc/apt/
After a reboot I then changed all "dapper" into "edgy" in the sources.list and updated the whole system once again. There were a few question during that update that I all answered with "yes". Also, I deleted "splash" and "quiet" in the /boot/grub/menu.lst
After a reboot the system came up correctly, including the desktop. The system could also be correctly shutdown/reboot.
But then, adept updater showed that there were updates available. I ran through all of them, made a reboot and then the error showed up: I could enter the password but then the laptop ran into the known issue. Also, a shutdown/reboot isn't no longer possible.
As attachment, you can see what packages are concerned after the correct bootup of edgy but before running the adept-updater.
Greets,
khymon
Fabio Berta (fberta) wrote : | #62 |
I'm sorry, but this is still not working for me on an up to date feisty machine!
When splash is enabled, all I'm getting is upslash freezing when the bootup process is trying to mount the encrypted partitions and after a while it turns into a black screen, where i can't do anything.
If I remove "splash" from the bootup options I get the same errors I got in edgy. Meaning the crypt devices don't get activated and the system is trying to mount the encrypted ones, which of course fails.
Any help here?
Lennart Hansen (lahansen) wrote : | #63 |
Hi Marc,
Just FYI, I've tested your Edgy patch [1], and it doesn't work for me, didn't dig much into why, found it not working and reversed the changed and went back to the old, break usplash and ask for password fix from the beginning of this thread.
[1] : https:/
Happy christmas.
Lennart Hansen (lahansen) wrote : | #64 |
Ok, decided to dig into it anyway.
Found that I didn't have a Luks volume [0] and that was the reason for this not to work.
When I installed encrypted filesystem I used guide [1], which does not use luks volumes.
Think maybe the bug reports marked as duplicates was about both methods.
So I tried reinstalling a brand new Edgy and used guide [2] which uses luks volumes.
I did not do the whole encrypted root thingy, just the home partition.
After patching /lib/cryptsetup
and added "home /dev/sda3 none luks" to my /etc/crypttab it worked great!
Thanks,
[0]: /sbin/cryptsetup isLuks /dev/sda3
[1]: https:/
[2]: https:/
[3]: https:/
Fabio Berta (fberta) wrote : | #65 |
Please ignore my last comment! My /etc/crypttab was fucked up... I can configm Lennart's observations; It's working with luks devices but not with the old ones!
Also one problem remains for me. If I have the "quiet" parameter in the boot options my keyboard is just not working during the boot process! Meaning I can't enter my passphrase! Very strange!
John Leach (johnleach) wrote : one line fix for Edgy | #66 |
A quick fix I found on Edgy was to change line 294 in /lib/cryptsetup
$CRYPTCMD $PARAMS luksOpen $src $dst <&1
to:
$CRYPTCMD $PARAMS luksOpen $src $dst < /dev/console
Now it jumps to console from splash on boot and asks for password.
maikischa (maikisch) wrote : Re: Upstart doesn't activate luks volumes in cryptsetup | #67 |
According to "one line fix for Edgy" by John Leach:
Don't forget to also change line 318 (no_luks) also
from:
$CRYPTCMD $PARAMS create $dst $src <&1
to:
$CRYPTCMD $PARAMS create $dst $src < /dev/console
Now it should work for al people who have the new edgy cryptdisks.function
Stefan Rehm (stefan-rehm) wrote : | #68 |
- cryptdisk.functions usplash patch Edit (14.2 KiB, text/plain)
Hi,
when I tried Marc`s patch for edgy, I stumbled across a major security issue. When usplash exits early (as it does for example on a fsck on my machine) the entered password is echoed plain text on the console. So I think it`s not such a good idea to attach to a console when usplash is running.
I then made altered the first few lines of cryptdisk.functions in the following way:
pgrep usplash
if [ $? -gt 0 ]; then
USPLASH_
else
USPLASH_
fi
stdin=`readlink /proc/self/fd/0`
if [ "${stdin#
exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` -w $0 "$@"
fi
The attached patch is a modified version of Marc`s patch, that adds these changes.
Now it works perfectly for me using LUKS volumes (a quick test showed that other dm-crypt devices are still ignored when usplash is active).
Stefan Rehm (stefan-rehm) wrote : | #69 |
- cryptdisk.functions usplash patch v1.1 Edit (14.2 KiB, text/plain)
Ups, missed two quotation marks in the patch file. Another example of one error fixing another error ;).
Stefan Rehm (stefan-rehm) wrote : | #70 |
Ok, forget it. The patch is wrong and totally useless :(. Guess it was just luck and bad testing, that the error didn`t occur afterwards.
The problem still remains!
Add usesplash_write "QUIT" below usplash_write "CLEAR" in function do_luks() to force it. If such an early termination of usplash is caused by any event during boot (as it did here), someone looking over your shoulder might get some interesting information...
Max Ischenko (ischenko) wrote : | #71 |
I did Edgy upgrade yesterday and run into the same problem with my /home partition.
After some trial and error, "two line fix for Edgy" by John Leach & maikischa worked for me: patch do_luks() and do_noluks() functions in /lib/cryptsetup
I also edited boot command line to disable splash screen. Ugly, but works.
Looking forward to seeing a proper fix being rolled out for Edgy.
Stefan Rehm (stefan-rehm) wrote : | #72 |
- cryptdisks.functions usplash patch v2.0 Edit (23.7 KiB, text/plain)
Did you try Marc Schiffbauer`s Patch (https:/
Extending the patch to support other dm-crypt volumes is only a matter of modifying the do_noluks() function in the same way as he did with do_luks().
There is already a bug report (#55159) for the password echoing. This is caused by usplash not disableing the echo of its stdin.
With the "stty" command it is still possible to disable it in any shell script, but this is IMHO definitivly the wrong place (otherwise the usplash INPUTQUIET function should be renamed INPUTHIDDEN ;) ). But as the bugreport is still undecided it seems necessary to (temporarily) fix it in cryptdisks.
The attached patch is again based on the original patch by Marc Schiffbauer and adds both no_luks usplash support and disabled stdin echo (by guarding usplash_write commands with "stty --file=$stdin -echo"). It also checks more strictly for a running usplash daemon as the existance of the fifo files just indicates that there once was a daemon running, but this may not be the case anymore when the function is called (at least they dont seem to get deleted).
I tested it over the weekend with standard dm-crypt and Luks volumes using keyfiles and passphrases to decrypt and (unlike my last futile attempt) this one worked fine with or without usplash. I did not test ssl and gpg encrypted keyfiles since there was no change within the keyscripts.
Max Ischenko (ischenko) wrote : | #73 |
I didn't bother with Marc's patch when I found a one-liner and I'm OK without usplash.
Hunz (ubuntu-hunz) wrote : | #74 |
I 'fixed' (since stty -echo didn't work) the password echo problem using this trick:
added echo -n -e "Enter password: \033[40;30m" before the
$CRYPTCMD $PARAMS create $dst $src ... line
and echo -n -e "\033[40;37m" after it
it sets the fore+background color to black/black using an ansi color escape sequence and restores it to white/black using the same method afterwards
not nice but works for me
:-]
Reinhard Tartler (siretart) wrote : | #75 |
cryptsetup (2:1.0.4-8ubuntu2) feisty; urgency=low
.
* fix and improve initramfs hook: terminate usplash if running, since
adequate secure text input is not possible with usplash ATM
* usplash support: Terminate usplash before asking a password.
Closes https:/
Changed in cryptsetup: | |
status: | In Progress → Fix Released |
Lars Volker (lv) wrote : | #76 |
today i spent a whole 10hours on updating from dapper to edgy. Most of the time i spent while trying to debug the latest cryptsetup-package i compiled from feisty sources - with the final conclusion that it couldn't work on my installation because the patches suggested in this bug rely on /usr/bin/openvt which won't work for anyone who has /usr on a separate volume like i do.
I can't however think of a better circumvention than commenting out that lines and replacing <&1 by "< /dev/console > /dev/console 2>&1" where necessary.
Would one with greater knowledge of the situation please change the scripts to make them run on systems with separate /usr.
Thanks
Lars
Sven Lilienthal (sven-lilienthal) wrote : | #77 |
Using feisty with cryptsetup 2:1.0.4+
Which means I have to wait a moment until usplash terminates ,enter the password and afterwords switch to console 1.
Hamish Downer (mishd) wrote : | #78 |
Don't know if it's related but the latest cryptsetup update in edgy appears to have broken setting up my (non luks) partition. I have usplash turned off, but have been unable to get a passphrase prompt. I have tried manually putting in the fixes to /lib/cryptsetup
The version of cryptsetup I now have is 2:1.0.4+
$ sudo cryptsetup --version
cryptsetup-luks 1.0.5
More on ubuntuforums at
loko (arph) wrote : | #79 |
like mish, i have the same problems with 2:1.0.4+
it totally broke my system. i couldn't mount the encrypted home-partition.
i switched back to 1.0.3, but now i get this error, the password-promt on boot is not shown anymore, except this error:
"enter passphrase: command failed: key reading error"
it's annyoing that this bad piece of software is released as a "tested" update.
what has this update done to my system in case that even downgrade to 1.0.3 didn't solve the problems?
Hamish Downer (mishd) wrote : | #80 |
A little further information. On my other (luks) system it works fine. Anyone got ideas as to what might be the non-luks specific bug?
Ondřej Nový (onovy) wrote : | #81 |
you must edit /etc/crypttab and add to last row: 'vol_id'
in previous version this was default, now you must explicit add it.
my crypttab:
onovy@lajka:~$ cat /etc/crypttab
# <target device> <source device> <key file> <options>
crypt /dev/hda2 none vol_id
loko (arph) wrote : | #82 |
ok, adding vol_id does the trick.
i now installed feisty and there is no need to add vol_id anymore. but i got another problem.
The boot-splash switches to console, where i can see "Starting Cryptodisks" (or similar message) but it didn't go automaticaly to the next step, "Enter Passphrase".
I always have to press a button (not enter, only the letters do it) then the console switch to the message "Enter Passphrase" and now i can enter the password. Without pressing a letter-button, nothing happens and it waits forever.
Changed in cryptsetup: | |
status: | Fix Released → Confirmed |
sander (sander2) wrote : | #83 |
hi!
tonight i installed the latest feisty and set up an encrypted root partition. the enter passphrase dialog showed up but was interrupted by some USB kernel messages. after pressing enter the enter passphrase dialog showed up again and i entered my (correct) passphrase. i got a message that the passphrase is wrong. after reading this bug report i tried adding another *simple* passphrase that doesn't contain any "strange" symbols like ~. using the simple passphrase i can unlock the keyslot! looks like you can't enter symbols that need "two fingers", or at least you can't have a ~ in your passphrase!
Gabriel Ambuehl (gabriel-ambuehl) wrote : Re: [Bug 62751] Re: Upstart doesn't activate luks volumes (also non luks) in cryptsetup | #84 |
> can't enter symbols that need "two fingers", or at least you can't have a ~
> in your passphrase!
Could it be that you use a non US keyboard before the keymap is actually
initialize?
Fabián Rodríguez (magicfab) wrote : | #85 |
Let me know if I can help reproducing / testing this bug. I could test this on most any Ubuntu version pretty quickly.
Fabián Rodríguez (magicfab) wrote : | #86 |
As this package is in the " universe " repository, is is unlikely it will get any non-critical / non-security updates in any other versions than Gutsy. If anyon can test this against Gusty Tribe 4, I think it would help in determining if this bug can be closed.
There have been a number of updates since 1.0.4+svn26-
http://
Floris Bruynooghe (flub) wrote : | #87 |
Additional issue with crytroot setup in initramfs.
Usplash exits as it should, and the password gets read from console. However the password prompt is never displayed. To solve this I changed line 210 (feisty) from:
$cryptcreate < /dev/console
to
$cryptcreate < /dev/console > /dev/console 2>&1
Hope this is useful
Reinhard Tartler (siretart) wrote : | #88 |
I have to admit that I lost a bit track of this bugreport. In gutsy, I don't have any problems mounting my LUKS volume. I see a lot of feisty reports in this bugreport, which probably won't get fixed, please open another bugreport with [feisty] in the subject.
Is anyone seen this problem in gutsy for now?
Gabriel Ambuehl (gabriel-ambuehl) wrote : | #89 |
Works ok in Gutsy for me. At least for non root volumes, as I don't have
cryptroot myself.
faithful (strangecode) wrote : | #90 |
In Gutsty doesn't work for me the error I get is this:
exec: 34: env: not found.
I use luks with keyfiles so commented out this lines in /lib//cryptsetu
## Always output to console
#stdin=`readlink /proc/self/fd/0`
#if [ "${stdin#
# exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` -w $0 "$@"
#fi
This fixes my configuration but isn't a solution.
Cryptsetup version: 2:1.0.5-1ubuntu3.
Reinhard Tartler (siretart) wrote : | #91 |
faithful <email address hidden> writes:
> In Gutsty doesn't work for me the error I get is this:
> exec: 34: env: not found.
> I use luks with keyfiles so commented out this lines in /lib//cryptsetu
> ## Always output to console
> #stdin=`readlink /proc/self/fd/0`
> #if [ "${stdin#
> # exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` -w $0 "$@"
> #fi
> This fixes my configuration but isn't a solution.
>
> Cryptsetup version: 2:1.0.5-1ubuntu3.
Scott, you added that part above to the cryptsetup initramfs scripts. I
pretty sure that env used to be in the initramfs, but now isn't
anymore. Do you know if there is a variant of the above which doesn't
use {/usr,}/bin/env?
affects ubuntu/cryptsetup
assignee keybuk
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Changed in cryptsetup: | |
assignee: | siretart → keybuk |
Kjell Braden (afflux) wrote : | #92 |
Reinhard, correct me if I'm wrong but isn't the init.d call to cryptdisks.
I'm running gutsy, and this configuration works fine:
$ cat /etc/crypttab
croot32 /dev/sda11 none luks,cipher=
chome32 /dev/sda12 none luks,cipher=
cvar32 /dev/sda13 /cvarfile luks,cipher=
cswap /dev/sda6 /dev/urandom swap
$ cat /etc/fstab
/dev/mapper/croot32 / ext3 defaults,
LABEL=cvar32 /var ext3 defaults 0 1
LABEL=chome32 /home ext3 defaults 0 1
/dev/mapper/cswap none swap sw 0 0
The only patch I use is for usplash:
--snip--
--- /lib/cryptsetup
+++ /lib/cryptsetup
@@ -271,11 +271,15 @@
- /sbin/usplash_write "QUIT"
- # saftey sleep !
- sleep 2
+ while [ "$tried" -lt "$TRIES" ]; do
+ usplash_write "INPUTQUIET Enter password for $dst ($src): "
+ PASS="$(cat /dev/.initramfs
+ echo -n "$PASS" | cryptsetup $PARAMS luksOpen $src $dst > /dev/null 2>&1 && break
+ tried=$(( $tried +1 ))
+ done
+ else
+ cryptsetup $PARAMS luksOpen $src $dst <&1
- cryptsetup $PARAMS luksOpen $src $dst <&1
fi
fi
--snip--
Hope that helps.
Reinhard Tartler (siretart) wrote : | #93 |
no it doesn't. You are reenabling password input in usplash, which isn't a good idea with current usplash
(try switching virtual consoles when entering your password to find out why)
Kjell Braden (afflux) wrote : | #94 |
Well, when starting without the splash parameter, everything works fine, too. I meant to say that I've done no changes to the cryptdisk.functions that would matter for this issue ;)
Changed in cryptsetup: | |
assignee: | keybuk → nobody |
Scott James Remnant (Canonical) (canonical-scott) wrote : | #95 |
env exists as a magic built-in in the initramfs busybox
Reinhard Tartler (siretart) wrote : | #96 |
faithful: Please check if you really have no /usr/bin/env. (which is in coreutils). Your system seems to be broken in strange ways.
Gabriel: are you still experiencing this bug with current gutsy? I'm using cryptsetup on several machines in several configuration, and had no problems mentioned in this bugtrail. I'm therefore inclined to assume that the Problem of the original reporter has been fixed in the mean time.
Reinhard Tartler (siretart) wrote : | #97 |
need more input on this bug
Changed in cryptsetup: | |
status: | Confirmed → Incomplete |
Reinhard Tartler (siretart) wrote : | #98 |
zak, I'm rejecting the loop-aes-utils subtask, because this bug clearly isn't about that part. at least, it is not visible at in in the bugtrail what would need fixing in the loop-aes-utils package. If you still have the bug, please file a new bug. thanks
Changed in loop-aes-utils: | |
status: | New → Invalid |
faithful (strangecode) wrote : | #99 |
Ok my problem is resolved. Recent updates solved it.
Thanks.
Reinhard Tartler (siretart) wrote : | #100 |
Due to the lack of responses that anyone can still confirm that the described problem still appears, and the recent feedback that an unrelated issue has been solved (thanks faithful for reporting back), I come to the conclusion that this bug has been fixed some time ago. I cannot really reproduce it in gutsy. I'm therefore closing this bug.
Please, if you think this bug is still valid, please consider filing a new bug with a clearer description than this one. Thanks!
Changed in cryptsetup: | |
assignee: | nobody → siretart |
status: | Incomplete → Fix Released |
gpaharenko (gpaharenko) wrote : | #101 |
A problem still exists:
ubuntu-
loko (arph) wrote : | #102 |
I have to say that this bug is not completely solved.
Some problems still exist. this is what i experience.
Using gutsy, up-to-date as of 08.03.2008
Encrypted partitions: home and swap
Type of encryption: Luks
crypttab:
home /dev/sda3 none luks,retry=
swap /dev/sda4 /dev/random swap
fstab:
/dev/mapper/home /home ext3 defaults 0 0
/dev/mapper/swap none swap sw 0 0
During boot-up the following behavior i can report:
boot-up starts, splash goes away and i see "Starting early crypto disks..."
then there is "Enter LUKS passphrase:"
And i enter the passprase. After that i press "Enter" and can see "key slot 0 unlocked. command successful"
but then boot doesn't continues until i move my fingers over the touchpad. well, pressing any key doesn't let the boot-process continuing.
so it seems that there is an input expected which in my case only with the touchpad can be made.
after moving the fingers over the pad, i can see "Starting remaining cryptodisks..." and boot-up goes on.
could it be, that the swap is the problem or the order of the lines in the fstab/crypttab
Could this be explained and or confirmed by somebody?
Changed in cryptsetup: | |
status: | Fix Released → Confirmed |
loko (arph) wrote : | #103 |
Well it seems that is is a problem with the encrypted swap.
i changed the lines in fstab and crypttab this way:
fstab:
/dev/mapper/swap none swap sw 0 0
/dev/mapper/home /home ext3 defaults 0 0
crypttab:
swap /dev/sda4 /dev/random swap
home /dev/sda3 none luks,retry=
in fact, it seems that for the encrypted swap an input is needed otherwise boot does not go on.
so in this case, i first see "Starting early crypto disks..."
and then nothing comes until i move my fingers over the touchpad. after i did this, "Enter LUKS passphrase" appears.
I enter it, press "enter" and boot-up goes on.
So is this a upstart problem, or a configuration problem?
Patrick J. LoPresti (lopresti) wrote : | #104 |
/dev/random blocks until it has enough entropy to guarantee
randomness. That is probably why wiggling the touchpad gets things
going again.
If you have /dev/hwrandom, you can use that... Otherwise, you can use
/dev/urandom to avoid blocking, but theoretically this could give up
some security (since the random generator's internal state could be
predictable at boot).
Hamish Downer (mishd) wrote : | #105 |
I think your problem is related to using /dev/random in your crypttab
swap /dev/sda4 /dev/random swap
/dev/random collects entropy from different parts of the system (including mouse/touchpad usage). I'm not sure, but I suspect entropy is not saved at shutdown, so entropy must be collected again at start up. /dev/random will block without enough entropy, and using the touchpad is putting some entropy into the random number system.
If you want it to not block, try using /dev/urandom instead. It is not quite as secure, but I think it is more than secure enough for the key for the swap partition.
For more on the differences between /dev/random and /dev/urandom, see
$ man urandom
(On reading that it mentions a way to save entropy on shutdown, though I think you would want to change the place to save it to not in /var/run as that is a filesystem in RAM created by ubuntu on start up).
Changed in cryptsetup: | |
status: | Confirmed → Fix Released |
loko (arph) wrote : | #106 |
Patrick J. LoPresti and mish,
thank you both for the help.
indeed /dev/random is the problem. Like mish said i could use /dev/urandom. I don't have /dev/hwrandom, so the urandom solution or the script mentioned in the manpage of random is the one i need.
As a theoretically question, how can i use this script mentioned in the manpage? Mishs tip is helpful not to save entrophy in /var/run. but i stuck with putting the scripts at the right place.
I put them to /etc/rcS.d for sart-up and there i put it with a name like S25... but this seems not to working as i get something like "dd: cat unknown command" or something equal like that.
the shutdown-script i put in rc0.d and rc6.d but also there i don't know if this is correct and which numbers i should use. i assume it should be something like S... because if i understand this right, S is for starting the script. rc0.d and rc6.d are for shutdown and restart, if i am right.
can somebody help me with this please.
thanks in advance
Patrick J. LoPresti (lopresti) wrote : | #107 |
What version of Ubuntu are you using?
On mine (7.10 aka. Gutsy), /etc/init.d/urandom already propagates the
random seed across reboots in /var/lib/
This should make /dev/urandom very safe to use, assuming that file
itself is never compromised.
loko (arph) wrote : | #108 |
I use 7.10 but i didn't know that urandom saves the random seed during start, restart and shutdown.
Everywhere on the net there can be read that urandom is not as secure as random is. but i am a bit confused now. how could it be that urandom is not as secure as random if uradom just saves the entropy of random and resores it when it's needed.
can you explain this to me?
Patrick J. LoPresti (lopresti) wrote : | #109 |
It's a long story that depends on how you define "random" and
"secure". And this is really the wrong forum for this question and
answer. But I'll give it a whack anyway. :-)
/dev/random never hands out more bits than it has entropy available.
(It collects entropy from the timings of keyboard interrupts, mouse
interrupts, and the like; and it tries to conservatively estimate how
many bits of randomness each event adds to the pool.) If the entropy
estimator is conservative -- which its creators believe but which is
impossible to prove -- then /dev/random is perfectly random and
perfectly secure, in the sense that, from an attacker's point of view,
any one of the 2^N possible strings of N bits is equally likely to be
output.
/dev/urandom hands out as many bits as you ask for, using the truly
random state of /dev/random as a seed for a cryptographic
pseudo-random number generator (PRNG). So even if the /dev/random
entropy pool only has (say) 256 bits of entropy, /dev/urandom will
gladly give you 1000, 1 million, or 1 billion bits of output. In this
example, since there are only 256 bits of entropy, there are only
2^256 possible outputs, so each of the 2^1000, 2^(1 million) or 2^(1
billion) possible outputs from /dev/urandom is NOT equally likely. In
this sense, /dev/urandom is "less secure" than /dev/random. If the
PRNG is cryptographically strong -- which its creators believe but
which is impossible to prove (at present) -- then there is no
*practical* way to distinguish the output of /dev/random from that of
/dev/urandom... Because for practical purposes, 2^256 might as well
be 2^1000.
The point of preserving the entropy pool across reboots is to give the
entropy pool an initial state that is unknown to any attacker. In
other words, even if the attacker knows a lot about your system --
like what state it is in when you first turn it on -- he will not know
anything about your entropy pool as long as he does not know what is
in the saved state file.
Does this help?
loko (arph) wrote : | #110 |
Yes that helps.
Thank you for the explanation.
Josef Wolf (jw-raven) wrote : | #111 |
I have this problem after an upgrade from 9.04 to 9.10. With 9.04, the boot was interrupted and resumed again after I entered the passphrase
After upgrade to 9.10, the passphrase prompt appears and immediately the graphical login screen appears. I switch back with ALT+CTRL+F1, but no keystrokes are accepted. When I switch to tty2 and login, I can see cryptsetup and pinentry programs nag. I have to kill them several times, since they are restared again and again.
Eventually, cryptdisks gives up, but still a simple "/etc/init.
affects: | upstart → null |
no longer affects: | null |
Not an upstart bug, cryptsetup is incorrectly accessing the console to ask for input during boot