Ubuntu

pam_mount unable to unmount needs root priv

Reported by Kalisto on 2007-05-30
130
This bug affects 21 people
Affects Status Importance Assigned to Milestone
PAM
In Progress
Unknown
Debian
Fix Released
Unknown
libpam-mount (Ubuntu)
Medium
Unassigned
Declined for Jaunty by Mathias Gug
openssh (Ubuntu)
Undecided
Unassigned
Declined for Jaunty by Mathias Gug
shadow (Ubuntu)
Undecided
Unassigned
Declined for Jaunty by Mathias Gug

Bug Description

Binary package hint: libpam-mount

From pam_mount developer Jan Engelhard sourceforge mailing list:
"pam_mount *needs* the root privileges, but Ubuntu's PAM configuration
decided to throw them away after the login sequence completed."

From Ubuntu Feisty Fawn user Kalisto:

"When using loopback encrypted file systems this is a security issue, user logs out but the device is not umounted!!
Without pam_mount debug option set this is not immediately apparent to the user!

I have followed the instructions on: http://felipe-alfaro.org/blog/2006/08/19/encrypted-home-on-ubuntu-using-cryptoloop/

To create a loopback encrypted home directory with pam_mount.
The dir mounts ok and seemes to work however on logout I get " error setting uid to 0"
lsof -n | grep /home/crypto comes up empty.

I have included a pam_mount debug output for the login and logout process:
For easier viewing: http://rafb.net/p/HLVzwm40.nln.html

user@trinity:su crypto
pam_mount(pam_mount.c:461) pam_sm_open_session: real uid/gid=0:1001, effective uid/gid=0:1001
pam_mount(readconfig.c:418) checking sanity of volume record (/home/crypto.img)
pam_mount(pam_mount.c:476) about to perform mount operations

pam_mount(mount.c:368) information for mount:
pam_mount(mount.c:369) ----------------------
pam_mount(mount.c:370) (defined by globalconf)
pam_mount(mount.c:373) user: crypto
pam_mount(mount.c:374) server:

pam_mount(mount.c:375) volume: /home/crypto.img
pam_mount(mount.c:376) mountpoint: /home/crypto
pam_mount(mount.c:377) options: loop,user,exec,encryption=aes,keybits=128
pam_mount(mount.c:378) fs_key_cipher: aes-128-ecb

pam_mount(mount.c:379) fs_key_path: /home/crypto.key
pam_mount(mount.c:380) use_fstab: 0
pam_mount(mount.c:381) ----------------------
pam_mount(mount.c:177) realpath of volume "/home/crypto" is "/home/crypto"

pam_mount(mount.c:182) checking to see if /home/crypto.img is already mounted at /home/crypto
pam_mount(mount.c:755) /home/crypto.img already seems to be mounted at /home/crypto, skipping
pam_mount(pam_mount.c:123) clean system authtok (0)

pam_mount(misc.c:264) command: /usr/sbin/pmvarrun [-u] [crypto] [-o] [1]
pam_mount(misc.c:341) set_myuid(pre): real uid/gid=0:1001, effective uid/gid=0:1001
pam_mount(misc.c:376) set_myuid(post): real uid/gid=0:1001, effective uid/gid=0:1001

pam_mount(pam_mount.c:360) pmvarrun says login count is 3
pam_mount(pam_mount.c:493) done opening session
pam_mount(pam_mount.c:106) Clean global config (0)

===========================================================================

crypto@trinity:exit

exit
pam_mount(pam_mount.c:535) received order to close things
pam_mount(pam_mount.c:536) real and effective user ID are 1001 and 1001.
pam_mount(misc.c:264) command: /usr/sbin/pmvarrun [-u] [crypto] [-o] [-1]

pam_mount(misc.c:341) set_myuid(pre): real uid/gid=1001:1001, effective uid/gid=1001:1001
pam_mount(misc.c:346) error setting uid to 0
pam_mount(pam_mount.c:360) pmvarrun says login count is 2
pam_mount(pam_mount.c:564) crypto seems to have other remaining open sessions

pam_mount(pam_mount.c:569) pam_mount execution complete
pam_mount(pam_mount.c:535) received order to close things
pam_mount(pam_mount.c:536) real and effective user ID are 1001 and 1001.
pam_mount(misc.c:264) command: /usr/sbin/pmvarrun [-u] [crypto] [-o] [-1]

pam_mount(misc.c:341) set_myuid(pre): real uid/gid=1001:1001, effective uid/gid=1001:1001
pam_mount(misc.c:346) error setting uid to 0
pam_mount(pam_mount.c:360) pmvarrun says login count is 1
pam_mount(pam_mount.c:564) crypto seems to have other remaining open sessions

pam_mount(pam_mount.c:569) pam_mount execution complete
pam_mount(pam_mount.c:106) Clean global config (0)

===========================================================================
Entry in /etc/security/pam_mount.conf

volume crypto auto - /home/crypto.img /home/crypto loop,user,exec,encryption=aes,keybits=128 aes-128-ecb /home/crypto.key

/Kalisto"

Kalisto (orion1org) wrote :

Confirmed!

>Dameon Wagner schrieb:
>> pam_mount(misc.c:264) command: /usr/local/sbin/pmvarrun [-u] [tester]
>> [-o] [-1]
>> pam_mount(misc.c:341) set_myuid(pre): real uid/gid=1004:1004,
>> effective uid/gid=1004:1004
>> pam_mount(misc.c:346) error setting uid to 0
>> pam_mount(pam_mount.c:360) pmvarrun says login count is 1

>Before unmount, the login count must be zero, not 1. This is the reason
>pam_mount does no unmount.

But the problem is that the effective gid is not 0 anymore. I think this
privilegue-dropping is a bug ('feature gone wrong') in ubuntu.

>To reset the login count, remove the file /var/run/pam_mount/$USER. Then
>a login as $USER should increase the value in this file to one, and the
>logout decreases it again to zero. Then the volumes will be unmounted.
>
>Regards,
> Bastian
>pam-mount-user mailing list
>pam-mount-user@li...
>https://lists.sourceforge.net/lists/listinfo/pam-mount-user
>

Changed in libpam-mount:
status: Unconfirmed → Confirmed
Kalisto (orion1org) wrote :

Bug is caused by pam dropping root priv on pam_mount routine too early.

Jamie Strandboge (jdstrand) wrote :

Thank you for reporting the issue and helping to make Ubuntu even better. Is this still an issue on Ubuntu Gutsy?

Changed in pam:
status: Confirmed → Invalid
Changed in libpam-mount:
status: New → Incomplete

Yes, confirmed in gutsy.

David Tomaschik (matir) on 2008-01-06
Changed in libpam-mount:
status: Incomplete → New
Jeremy Kerr (jk-ozlabs) wrote :

Also present in hardy. pam_mount can't unmount on logout:

pam_mount(misc.c:285) command: /sbin/umount.crypt [/home/crypt/]
pam_mount(misc.c:56) set_myuid<pre>: (uid=1001, euid=1001, gid=1001, egid=1001)
pam_mount(misc.c:358) error setting uid to 0
pam_mount(mount.c:104) umount errors:
pam_mount(mount.c:107) You have to be root to use cryptsetup!
pam_mount(mount.c:107) umount: only root can unmount UUID=3d6517a4-b0b1-4e74-8b29-47853e187a13 from /home/crypt
pam_mount(mount.c:107) umount.crypt: error unmounting /home/crypt/
pam_mount(mount.c:596) waiting for umount
pam_mount(pam_mount.c:624) unmount of /dev/sda6 failed
pam_mount(pam_mount.c:635) pam_mount execution complete

This leaves the encrypted volume mounted, and attached to the device mapper (/dev/mapper/_dev_sda6 allows access to the unencrypted data). This allows access to the volume in plaintext after the user has logged out.

Jeremy Kerr (jk-ozlabs) wrote :

The login-count bug mentioned in comment 1 is also a symptom of the early-priv-dropping problem. When pam_mount decreases the login count to 0, it tries to remove the /var/run/pam_mount/$USER file, but can't as it doesn't have the privileges to do so. This results in a stale login count file.

redguy (mateusz-kijowski) wrote :

"pam_mount *needs* the root privileges, but Ubuntu's PAM configuration
 decided to throw them away after the login sequence completed."

Isn't this trivial to fix? Come on, this bug has been open for almost a year...

Marc Gariépy (mgariepy) wrote :

I've been looking in the diff of the pam source package for the parameter causing the privilege drop, but i've not been able to find such parameter. I looked for "drop" and "privilege" and "root" and found nothing useful. Configure from "rules" file doesn't have options that apprents to drop privileges. I didn't saw any reference to this options in the documentation of PAM. So, what is different between pam in Ubuntu and in other distributions?

Marc Gariépy (mgariepy) wrote :

I have tested the pam_mount on madriva 2007.0, build it from the ubuntu source and it work fine on mandriva. The problem seem really to be in pam under Ubuntu.

Craig Szymanski (cszymanski) wrote :

I am also having the same problem on a Hardy LTSP server. I have pam_mount connecting to cifs filesystems. The users network folders are mounted 3 different locations: ~/MyDocuments, ~/Public, ~/MultimediaShare
They show up on the desktop as a mounted drive. I can unmount them as the user in a terminal with umount.cifs "path".
As a workaround I tried adding umount.cifs commands to: /etc/gdm/PostSession/Default, but these do not seem to work from a LTSP client or from the server.

Dustin Kirkland  (kirkland) wrote :

I'm experiencing this problem on Hardy and Intrepid. Marking Confirmed.

:-Dustin

Changed in libpam-mount:
importance: Undecided → Medium
status: New → Confirmed
Dustin Kirkland  (kirkland) wrote :

Also, see:
 * http://dev.computergmbh.de/gitweb.cgi?p=pam_mount;a=blob;f=doc/faq.txt

Specifically, " Q. Why does pam_mount not work right with OpenSSH?"

I am only seeing this behavior on ssh logins. Console logins seem to work.

:-Dustin

Dustin Kirkland  (kirkland) wrote :

This is perhaps a problem with Debian's pam policy.

Running a Fedora9 KVM, the following /etc/pam.d/system-auth works for me (+++ denotes "added" to stock config):

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
+++auth required pam_mount.so try_first_pass
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
+++session optional pam_mount.so try_first_pass

Dustin Kirkland  (kirkland) wrote :

I added a watcher to the upstream bug report.

Also, I added openssh-server as being affected. Not necessarily that sshd needs changes, but more for tracking and visibility.

According to my code inspection of the OpenSSH code that opens and closes PAM sessions, it looks to me that the pam_open_session() happens with uid=0, which allows pam_mount to do the things it needs to do as root (namely, (a) mount filesystems and (b) increment /var/run/pam_mount/user).

On the other hand, sshd initiates pam_close_session() with uid=non-zero. The pam_mount setuid(0) therefore fails, and the pam_mount process has insufficient privilege to (a) unmount filesystems, and (b) decrement/remove /var/run/pam_mount/user.

Various sources note that one can disable ssh's privilege separation in /etc/ssh/sshd_config to solve this problem, at the expense of lowered security. I was not able to make this work on an Ubuntu Intrepid system. In any case, lowering the security shouldn't be a viable solution.

This is a longstanding bug that could really use some attention such that pam_mount could deliver its designed functionality even over ssh connections.

:-Dustin

Changed in pam:
status: Unknown → In Progress
Joachim Breitner (nomeata) wrote :

iI have linked a related Debian bug. This seems to be fixed in the new openssh version 5.1, according to http://packages.qa.debian.org/o/openssh/news/20080725T104703Z.html

Is this fix important enough to warrant a backport for hardy?

Joachim Breitner (nomeata) wrote :

I compiled openssh 5.1 from intrepid on hardy, but it still does not work. Strangly, I’m no longer getting an error message from mod_pam that setuid fails, although pam_unix reports that the session is actually closed.

Joachim Breitner (nomeata) wrote :

Nevermind, it worked after all. The remaining problem was a left-over /var/run/pam-mount file. It still doesn’t work for su, BTW.

Marc Gariépy (mgariepy) wrote :

With CIFS mount points, we observe the right behavior under hardy.

Oct 29 16:31:44 mxapp-126-1-1 gdm[19596]: pam_mount(misc.c:285) command: umount [/home/DemoElvSec]
Oct 29 16:31:44 mxapp-126-1-1 gdm[20985]: pam_mount(misc.c:56) set_myuid<pre>: (uid=0, euid=0, gid=602, egid=0)
Oct 29 16:31:44 mxapp-126-1-1 gdm[20985]: pam_mount(misc.c:56) set_myuid<post>: (uid=0, euid=0, gid=602, egid=0)
Oct 29 16:31:45 mxapp-126-1-1 gdm[19596]: pam_mount(mount.c:596) waiting for umount
Oct 29 16:31:45 mxapp-126-1-1 gdm[19596]: pam_mount(pam_mount.c:635) pam_mount execution complete
Oct 29 16:31:46 mxapp-126-1-1 gdm[19596]: pam_mount(pam_mount.c:116) Clean global config (0)
Oct 29 16:31:46 mxapp-126-1-1 gdm[19596]: pam_mount(pam_mount.c:134) clean system authtok (0)

Marc Gariépy (mgariepy) wrote :

I should mention that it's working with gdm.

'su' mounts, but doesn't unmount
'ssh' doesn't mount at all

mannheim (kronheim) wrote :

This bug is affecting me when logging in via gdm in hardy. My home directory is encrypted in /dev/sda6. Steps to reproduce (after setting up pam_mount etc. in Ubuntu 8.04.1):

1. Log in as me (bill) via gdm.
2. Log out.
3. Log in as joe, a member of admin group.
4. As joe, do
         $ sudo mkdir /mnt/bills-secrets
         $ sudo mount /dev/mapper/_dev_sda6 /mnt/bills-secrets

Actual results: the plain text partition is visible to bill.
Expected results: when bill logs out, the crypto mapping is taken down.

Other information: ----

My /var/log/auth.log shows:

> Nov 4 15:11:42 foo-machine gdm[6157]: pam_mount(pam_mount.c:624) unmount of /dev/sda6 failed

I have also noticed that logout takes a few more seconds than expected when the home directory is mounted this way via encryption and pam_mount. Perhaps this delay is another symptom of the problem.

The relevant line in my /etc/security/pam_mount.conf.xml is

<volume user="bill" fstype="crypt" path="/dev/sda6" mountpoint="/home/bill" />

Joachim Breitner (nomeata) wrote :

Hi Mannheim,

are you sure this is caused by problems with missing root persmissions? In my experience, when gdm this bug does not appear (e.g. cifs mounts are unmounted properly), while it occurs when using ssh or su.

I’m assuming that your problem is a different bug.

Greetings,
Joachim

mannheim (kronheim) wrote :

Joachim,

No, I'm sorry, I don't know if missing root permissions is the problem in my case. Maybe open files is the problem. (Perhaps I need to turn on debugging in pam_mount.conf.xml to find out.)

Kees Cook (kees) on 2009-01-24
Changed in openssh:
status: New → Confirmed
RK (kubuntu-rk) wrote :

See Bug #48407 reported by RK on 2006-06-04 for a fix that makes it work for me.

pinus (pinus) wrote :

I suffer the same problem with the brand new jaunty. This security issue is still not fixed, more than two years later?

Craig Szymanski (cszymanski) wrote :

I tried a fresh install of jaunty. The pam_mount works for my LTSP server if I logon to the server (Active directory member (Likewise) and the mount points show up for each user and unmount on logout), but for the LTSP clients it does not work. I've opted out of the pam_mount option for putting a link to their home folders under the places menu.

Matthew Lye (matthew.lye) wrote :

Also confirmed on Jaunty.

Unfortunately this is an upstream bug that may take a while for some action to occur on.

Matthew Lye (matthew.lye) wrote :

After checking this bug appears to have been fixed upstream in OpenSSH 4.8

This should be rolled into Karmic Koala.

Matthew Lye (matthew.lye) wrote :

This issue was fixed in OpenSSH version 4.8. Karmic beta has 5.1.

Changed in openssh (Ubuntu):
status: Confirmed → Fix Committed
Matthew Lye (matthew.lye) wrote :

Worth noting that libpam-mount does not have a problem. Its SU that has the issue and the way it calls the umount as a user but mounts as root.

Matthew Lye (matthew.lye) wrote :

using su <user> will log a user in and mount the folder/drive correctly (as root). When the session ends the unmount will be attempted as user.

su under Fedora does not have this issue.

Colin Watson (cjwatson) on 2010-01-04
Changed in openssh (Ubuntu):
status: Fix Committed → Fix Released
Dirk Moermans (dirkmoermans) wrote :

The bug is still present in 11.04.

pam_mount(spawn.c:128): error setting uid to 0
pmvarrun(pmvarrun.c:457): could not unlink /var/run/pam_mount/sec: Permission denied
pam_mount(spawn.c:128): error setting uid to 0
pam_mount(mount.c:68): umount messages:
pam_mount(mount.c:72): umount: only root can unmount /dev/sda8 from /home/sec
pam_mount(mount.c:724): unmount of /dev/sda8 failed

Changed in shadow (Ubuntu):
status: New → Confirmed

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=11.10
DISTRIB_CODENAME=oneiric
DISTRIB_DESCRIPTION="Ubuntu 11.10"

Linux workstation 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 i686 i686 i386 GNU/Linux

andreas@workstation:/home$ exit
exit
pam_mount(spawn.c:128): error setting uid to 0

and in 11:10 its also presant. Time to fix this bug, or?

David Burke (bufke) wrote :

This seems to still be a problem in 12.04. On log out I get

pam_mount(spawn.c:128): error setting uid to 0
pam_mount(mount.c:69): umount messages:
pam_mount(mount.c:73): umount: /home/me/share is not in the fstab (and you are not root)
pam_mount(mount.c:752): unmount of share failed

This seems to be a big problem if you log out, lose network connection, and log in using pam-mount. The computer locks up and the user is unable to log in without a reboot. It's easily reproducible.

With pam mount log in. Then log out. Verify mounts are still up. Bring down networking. Log in (using su is fine). The terminal hangs. You never log in.

billdangerous (billdangerous) wrote :

The bug is still present.

Lars Behrens (lars-behrens-u) wrote :

Bug confirmed here for Precise.

That bug is definitely a show stopper for Ubuntu in in large heterogenous networks.

redguy (mateusz-kijowski) wrote :

And I've been complaining that the bug has been opened for a year ... 5 years ago

Steve Langasek (vorlon) on 2013-04-26
no longer affects: pam (Ubuntu)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.