Bug 463429 - (pam_mount-crypto) pam_mount fails to mount encrypted loop filesystem
pam_mount fails to mount encrypted loop filesystem
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pam_mount (Show other bugs)
9
i686 Linux
medium Severity urgent
: ---
: ---
Assigned To: Till Maas
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-23 08:57 EDT by Casimiro de Almeida Barreto
Modified: 2009-04-13 09:17 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-13 09:17:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Casimiro de Almeida Barreto 2008-09-23 08:57:29 EDT
pam_mount (pam_mount-0.48-2.fc9.i386) is not able to get the  password while trying to mount an encrypted filesystem...

That's what is shown in /var/log/messages:

When logging from KDM:

Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:258) pam_mount 0.48: entering auth stage
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:268) could not get password from PAM system
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:190) enter read_password
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:293) saving authtok for session code (authtok=0x98b7630)
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:436) pam_mount 0.48: entering session stage
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:457) back from global readconfig
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:459) per-user configurations not allowed by pam_mount.conf.xml
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(misc.c:46) Session open: (uid=0, euid=0, gid=501, egid=501)
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(rdconf2.c:190) checking sanity of volume record (/home/.xxx.img)
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:511) about to perform mount operations
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:364) information for mount:
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:365) ----------------------
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:366) (defined by globalconf)
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:367) user:          xxx
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:368) server:        (null)
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:369) volume:        /home/.xxx.img
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:370) mountpoint:    /home/xxx
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:371) options:       loop,encryption=aes-cbc-256,rw
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:372) fs_key_cipher: aes-256-cbc
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:373) fs_key_path:   /etc/pki/cryptofs/.xxx.key
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:374) use_fstab:     0
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:375) ----------------------
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:151) realpath of volume "/home/xxx" is "/home/xxx"
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:155) checking to see if /home/.xxx.img is already mounted at /home/casimiro
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:824) checking for encrypted filesystem key configuration
Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:831) decrypting FS key using system auth. token and aes-256-cbc
Sep 22 17:21:31 terra kdm[3143]: Unknown session exit code 0 (sig 6) from manager process

When logging from console:

Sep 22 17:21:39 terra login: pam_mount(pam_mount.c:258) pam_mount 0.48: entering auth stage
Sep 22 17:21:39 terra login: pam_mount(pam_mount.c:268) could not get password from PAM system
Sep 22 17:21:39 terra login: pam_mount(pam_mount.c:190) enter read_password
Sep 22 17:21:44 terra login: pam_mount(pam_mount.c:293) saving authtok for session code (authtok=0x87e24d8)
Sep 22 17:21:44 terra login: pam_mount(pam_mount.c:436) pam_mount 0.48: entering session stage
Sep 22 17:21:44 terra login: pam_mount(pam_mount.c:457) back from global readconfig
Sep 22 17:21:44 terra login: pam_mount(pam_mount.c:459) per-user configurations not allowed by pam_mount.conf.xml
Sep 22 17:21:44 terra login: pam_mount(misc.c:46) Session open: (uid=0, euid=0, gid=0, egid=0)
Sep 22 17:21:44 terra login: pam_mount(rdconf2.c:190) checking sanity of volume record (/home/.xxx.img)
Sep 22 17:21:44 terra login: pam_mount(pam_mount.c:511) about to perform mount operations
Sep 22 17:21:44 terra login: pam_mount(mount.c:364) information for mount:
Sep 22 17:21:44 terra login: pam_mount(mount.c:365) ----------------------
Sep 22 17:21:44 terra login: pam_mount(mount.c:366) (defined by globalconf)
Sep 22 17:21:44 terra login: pam_mount(mount.c:367) user:          casimiro
Sep 22 17:21:44 terra login: pam_mount(mount.c:368) server:        (null)
Sep 22 17:21:44 terra login: pam_mount(mount.c:369) volume:        /home/.xxx.img
Sep 22 17:21:44 terra login: pam_mount(mount.c:370) mountpoint:    /home/xxx
Sep 22 17:21:44 terra login: pam_mount(mount.c:371) options:       loop,encryption=aes-cbc-256,rw
Sep 22 17:21:44 terra login: pam_mount(mount.c:372) fs_key_cipher: aes-256-cbc
Sep 22 17:21:44 terra login: pam_mount(mount.c:373) fs_key_path:   /etc/pki/cryptofs/.xxx.key
Sep 22 17:21:44 terra login: pam_mount(mount.c:374) use_fstab:     0
Sep 22 17:21:44 terra login: pam_mount(mount.c:375) ----------------------
Sep 22 17:21:44 terra login: pam_mount(mount.c:151) realpath of volume "/home/xxx" is "/home/xxx"
Sep 22 17:21:44 terra login: pam_mount(mount.c:155) checking to see if /home/.xxx.img is already mounted at /home/xxx
Sep 22 17:21:44 terra login: pam_mount(mount.c:824) checking for encrypted filesystem key configuration
Sep 22 17:21:44 terra login: pam_mount(mount.c:831) decrypting FS key using system auth. token and aes-256-cbc
Sep 22 17:21:44 terra init: tty1 main process (3154) killed by ABRT signal
Sep 22 17:21:44 terra init: tty1 main process ended, respawning

The /etc/security/pam_mount.conf.xml is:

<?xml version="1.0" encoding="UTF-8"?>
<pam_mount>

<debug enable="1" />

<mkmountpoint enable="1" />

<fsckloop device="/dev/loop7" />

<mntoptions allow="nosuid,nodev,loop,encryption,fsck" />

<mntoptions require="nosuid,nodev" />

<lsof>/usr/sbin/lsof %(MNTPT)</lsof>

<fsck>/sbin/fsck -p %(FSCKTARGET)</fsck>

<losetup>/sbin/losetup -p0 "%(before=\"-e\" CIPHER)" "%(before=\"-k\" KEYBITS)" %(FSCKLOOP) %(VOLUME)</losetup>

<unlosetup>/sbin/losetup -d %(FSCKLOOP)</unlosetup>

<cifsmount>/bin/mount -t cifs //%(SERVER)/%(VOLUME) %(MNTPT) -o "user=%(USER),uid=%(USERUID),gid=%(USERGID)%(before=\",\" OPTIONS)"</cifsmount>

<smbmount>/usr/bin/smbmount //%(SERVER)/%(VOLUME) %(MNTPT) -o "username=%(USER),uid=%(USERUID),gid=%(USERGID)%(before=\",\" OPTIONS)"</smbmount>

<ncpmount>/usr/bin/ncpmount %(SERVER)/%(USER) %(MNTPT) -o "pass-fd=0,volume=%(VOLUME)%(before=\",\" OPTIONS)"</ncpmount>

<smbumount>/usr/bin/smbumount %(MNTPT)</smbumount>

<ncpumount>/usr/bin/ncpumount %(MNTPT)</ncpumount>

<fusemount>/sbin/mount.fuse %(VOLUME) %(MNTPT) "%(before=\"-o\" OPTIONS)"</fusemount>

<fuseumount>/usr/bin/fusermount -u %(MNTPT)</fuseumount>

<umount>/bin/umount %(MNTPT)</umount>

<lclmount>/bin/mount -p0 -t %(FSTYPE) %(VOLUME) %(MNTPT) "%(before=\"-o\" OPTIONS)"</lclmount>

<cryptmount>/bin/mount -t crypt "%(before=\"-o\" OPTIONS)" %(VOLUME) %(MNTPT)</cryptmount>

<nfsmount>/bin/mount %(SERVER):%(VOLUME) %(MNTPT) "%(before=\"-o\" OPTIONS)"</nfsmount>



<mntcheck>/bin/mount</mntcheck>

<pmvarrun>/usr/sbin/pmvarrun -u %(USER) -o %(OPERATION)</pmvarrun>

<volume fskeycipher="aes-256-cbc" options="loop,encryption=aes-cbc-256,rw" fskeypath="/etc/pki/cryptofs/.xxx.key" user="casimiro" mountpoint="/home/xxx" path="/home/.xxx.img" fstype="ext3" />

<volume fskeycipher="aes-256-cbc" options="loop,encryption=aes-cbc-256,rw" fskeypath="/media/disk/.yyy.key" user="developer" mountpoint="/home/yyy" path="/media/disk/.yyy.img" fstype="ext3" />

</pam_mount>


Anyways, it is possible to manually mount the file system using:

# openssl aes-256-cbc -d -in /etc/pki/cryptofs/.xxx.key | mount -p0 -o loop,encryption=aes-cbc-256,rw /home/.xxx.img /home/xxx
Comment 1 Till Maas 2008-10-08 11:40:49 EDT
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.
Comment 2 Jan Engelhardt 2008-10-17 11:55:44 EDT
>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.
Comment 3 Casimiro de Almeida Barreto 2008-10-17 12:36:03 EDT
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
Comment 4 Jan Engelhardt 2008-10-17 13:45:45 EDT
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.
Comment 5 Casimiro de Almeida Barreto 2008-10-17 14:35:59 EDT
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...
Comment 6 Jan Engelhardt 2008-10-17 15:56:15 EDT
>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).
Comment 7 Casimiro de Almeida Barreto 2008-10-19 10:57:34 EDT
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...
Comment 8 Till Maas 2009-04-13 09:17:09 EDT
Nobody should use a Fedora with an old pam_mount.conf config file anymore, therefore there is no need to debug the conversion script.

Note You need to log in before you can comment on or make changes to this bug.