Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#18103 - [pmount] doesn't prompt for passphrase after recent cryptsetup update

Attached to Project: Arch Linux
Opened by Jens Adam (byte) - Monday, 01 February 2010, 06:11 GMT
Last edited by Andrea Scarpino (BaSh) - Thursday, 10 June 2010, 13:18 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture i686
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

pmount is installed setuid root, I'm in the storage group, yet I can no longer mount my LUKS devices:

"Internal error: cryptsetup luksOpen failed"

Running pmount with sudo works, though.

A simple rebuild of pmount didn't fix it.
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Thursday, 10 June 2010, 13:18 GMT
Reason for closing:  Fixed
Additional comments about closing:  on trunk
Comment by Frank Carlyle McLaughlin (frankspace) - Wednesday, 03 February 2010, 00:26 GMT
I have this exact same error after the most recent upgrade. I note that pmount fails before prompting for a password, too - unless it is run with sudo, it generates that error immediately and without further prompting. Also, my system is x86_64.

Interestingly, this does NOT affect mounting my whole-disk encryption. Only my external drives.

That most recent upgrade included a lot of programs, but after sorting through it, I believe it included cryptsetup (1.0.7-1 > 1.1.0-1), device-mapper (2.02.53-1 > 2.02.60-2), and lvm2 (2.02.53-1 > 2.02.60-2). I suspect one of those might be the culprit, but I'm not knowledgeable enough to do more than hold that hunch (though I'm going to try process of elimination on another computer when I have a chance and report back). A Google search for "pmount cryptsetup luksopen failed" likewise resulted in what appears to be a multiply-mirrored Debian bug report from 2009 that I'm not smart enough to understand.
Comment by J. F. Mitre (mitre) - Sunday, 07 February 2010, 15:22 GMT
Frank, I agree with you. I don't use pmount, but I had the same problem.
I reinstalled the old versions of cryptsetup, device-mapper and devicekit-disks and the problem was resolved.
For now, they will be on the list of ignored packages (IgnorePkg = cryptsetup device-mapper devicekit-disks)
Comment by Thomas Bächler (brain0) - Sunday, 07 February 2010, 15:51 GMT
@mitre: That causes a ton of other problems and is not a good idea if you use encryption in your base system! The main problem is that the new device-mapper (and devicekit-disks) prevents udev from messing with the devices cryptsetup creates when it shouldn't, thus avoiding a ton of race conditions. The fact that it works as root tells me that something must be wrong in pmount - unfortunately, strace/ltrace will negate setuid and debugging is difficult.
Comment by Frank Carlyle McLaughlin (frankspace) - Sunday, 07 February 2010, 18:28 GMT
Sorry it's taken me so long to get back to this.

Using the latest version of devicekit-disks (009-4) has no effect on my systems. I don't think it was included in the batch of upgrades after which I saw this issue, so it didn't occur to me that it might be a problem.

Anyway, I can confirm that the issue is NOT in the latest version of device-mapper or lvm2. I held back both of those on my other box and upgraded ONLY cryptsetup (as noted, 1.0.7-1 to 1.1.0-1), and after a reboot, this issue appeared. So something changed in cryptsetup to cause this. So, mitre, holding back device-mapper and devicekit-disks is probably pointless.

I don't know anything about the race conditions brain0 discusses. Nor do I have any idea about whether this is a problem in cryptsetup or a problem in pmount. But it's the cryptsetup upgrade that does this on my system.
Comment by Thomas Bächler (brain0) - Sunday, 07 February 2010, 20:08 GMT
If the issue is unrelated to device-mapper and only related to cryptsetup, then it can only be that pmount uses some cryptsetup option that has been removed, or changed (in particular, this has nothing to do with the device-mapper changes and thus is no timing issue as I suspected). This has to be fixed in pmount then.

I don't have time to do this now, but you could try this (if you know how to): See if pmount has a "verbose" option that prints the cryptsetup command it executes. If not, go into the source and patch pmount such that it always prints the cryptsetup command to stderr before executing it. That will bring us a step closer to the problem.
Comment by J. F. Mitre (mitre) - Sunday, 07 February 2010, 22:49 GMT
@brain0: I don't use encryption in my base system. I read something about how it avoids some problems in another topic.

@frankspace: I thought the device-mapper influence the cryptsetup. In fact, I should have tested it.
Comment by Thomas Bächler (brain0) - Sunday, 07 February 2010, 23:49 GMT
Some small test with --debug:

spawnv(): executing /usr/sbin/cryptsetup '/usr/sbin/cryptsetup' 'isLuks' '/dev/loop0'
spawn(): /usr/sbin/cryptsetup terminated with status 0
spawnv(): executing /usr/sbin/cryptsetup '/usr/sbin/cryptsetup' 'luksOpen' '/dev/loop0' '_dev_loop0'
spawn(): /usr/sbin/cryptsetup terminated with status 234
Internal error: cryptsetup luksOpen failed

It works as root, like reported earlier.
Comment by Thomas Bächler (brain0) - Sunday, 07 February 2010, 23:55 GMT
I also patched pmount so that it doesn't redirect stdout and stderr, the error message is 'Cannot open device /dev/loop0.' (I am testing with /dev/loop0)
Comment by Dan Griffiths (Ghost1227) - Friday, 12 February 2010, 05:15 GMT Comment by Jens Adam (byte) - Saturday, 15 May 2010, 00:06 GMT
pmount 0.9.22 finally fixes this.
But now there's http://bugs.archlinux.org/task/19463

Loading...