Bug 463429 (pam_mount-crypto)
| Summary: | pam_mount fails to mount encrypted loop filesystem | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Casimiro de Almeida Barreto <casimiro.barreto> |
| Component: | pam_mount | Assignee: | Till Maas <opensource> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | casimiro.barreto, jengelh, opensource |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-04-13 13:17:09 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Casimiro de Almeida Barreto
2008-09-23 12:57:29 UTC
How did you create your crypto partition? It looks like you used cryptoloop. The support for this is deprecated in pam_mount, because it is not safe for filesystems with a journal, e.g. like ext3. What is the actual problem you have? Does pam_mount not mount your filesystem? Can you please test pam_mount-0.49-1, which is in updates-testing, soon? It fixes one bug that may appear in your setup, but I am not sure, that it is the one you are seeing. >Sep 22 17:21:44 terra init: tty1 main process (3154) killed by ABRT signal
Yeah, this is the stray assertion check that was left in.
Yes, it is cryptoloop. And yeah, I know about the security problems. But it is a legacy and I know of other people in the same situation. Just imagine migrating lots of user home directories that were previously working... pam_mount is not mounting cryptoloop partitions in my system. Other partitions it seems to be mounting OK. That's the actual problem. If support for cryptoloop was deprecated it should issue a more meaningful error message (kind of: support for this was deprecated) and not main process (3154) killed by ABRT signal I'll try pam_mount-0.49-1 thnx There is no specific piece of code in pam_mount that specifically enables the use of cryptoloop, so there is nothing I could remove. As such, it silently continues to work - for now. But your ABRT is likely caused by an assert() line that was unfortunately not removed during a change to support binary passwords (i.e. things that make it impossible to use the str* family of function like strlen). You should be seeing the exact assertion text in one of the logs (/var/log/auth it is in redhat I think), it should read "assert(ret == 0) failed" or so. This is, yes, fixed in v0.49 and beyond. No. I tested v0.49 and the problem stands. When system is MOUNTED (manually mounted) pam_mount creates the following record in /var/log/messages: Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(pam_mount.c:258) pam_mount 0.49: entering auth stage Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(pam_mount.c:268) could not get password from PAM system Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(pam_mount.c:190) enter read_password Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(pam_mount.c:293) saving authtok for session code (authtok=0x82b9600) Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(pam_mount.c:436) pam_mount 0.49: entering session stage Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(pam_mount.c:457) back from global readconfig Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(pam_mount.c:459) per-user configurations not allowed by pam_mount.conf.xml Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(misc.c:46) Session open: (uid=0, euid=0, gid=501, egid=501) Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(rdconf2.c:190) checking sanity of volume record (/home/.casimiro.img) Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(pam_mount.c:512) about to perform mount operations Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:364) information for mount: Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:365) ---------------------- Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:366) (defined by globalconf) Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:367) user: casimiro Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:368) server: (null) Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:369) volume: /home/.casimiro.img Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:370) mountpoint: /home/casimiro Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:371) options: loop,encryption=aes-cbc-256,rw Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:372) fs_key_cipher: aes-256-cbc Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:373) fs_key_path: /etc/pki/cryptofs/.casimiro.key Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:374) use_fstab: 0 Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:375) ---------------------- Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:151) realpath of volume "/home/casimiro" is "/home/casimiro" Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:155) checking to see if /home/.casimiro.img is already mounted at /home/casimiro Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(mount.c:801) /home/.casimiro.img already seems to be mounted at /home/casimiro, skipping Oct 17 14:29:43 terra kdm: :0[2629]: command: [/usr/sbin/pmvarrun] [-u] [casimiro] [-o] [1] Oct 17 14:29:43 terra kdm: :0[3805]: pam_mount(misc.c:46) set_myuid<pre>: (uid=0, euid=0, gid=501, egid=501) Oct 17 14:29:43 terra kdm: :0[3805]: pam_mount(misc.c:46) set_myuid<post>: (uid=0, euid=0, gid=501, egid=501) Oct 17 14:29:43 terra pmvarrun: pmvarrun(pmvarrun.c:203): parsed count value 2 Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(pam_mount.c:403) pmvarrun says login count is 3 Oct 17 14:29:43 terra kdm: :0[2629]: pam_mount(pam_mount.c:525) done opening session (ret=0) When system is not mounted, then we have the error specified in the description of the message. It seems that pam_mount is either passing the wrong arguments to mount or failing do do: openssl aes-256-cbc -d -in /etc/pki/cryptofs/.casimiro.key and pipe it to mount... >Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:268) could not get
password from PAM system
If it cannot get a password, it can't pass the correct one to mount. The details of this lie in your pam configuration for the particular login program (kdm in your case).
Ok. Poblem solved. It is not a bug in pam_mount but in the program that converts from the old pam_mount.conf to the new pam_mount.conf.xml As you can see in the original post, before the tags: <volume ... /> the converter let the tags: <mntcheck>/bin/mount</mntcheck> <pmvarrun>/usr/sbin/pmvarrun -u %(USER) -o %(OPERATION)</pmvarrun> As soon as I moved <volume ...> tabs just after the <nfsmount>...</nfsmount> system started to work properly. About the messages regarding to password, I just had to revert to the original *.rpmsave files... Nobody should use a Fedora with an old pam_mount.conf config file anymore, therefore there is no need to debug the conversion script. |