Bug 15479

I'll have a look, but, for sure, pam_mount never unmount filesystems which are used, as does umount. So I would not call that a bug.

Now, the second mounting is indeed not expected and I have never seen it mounting encrypted fs. I'll try to reproduce, could you attached any of the /etc/pam.d/* files you have modified?

cheers.

(In reply to Chris Denice from comment #1)
> I'll have a look, but, for sure, pam_mount never unmount filesystems which
> are used, as does umount. So I would not call that a bug.

umount works just fine, it just has to be run with root privileges (as does mount, hence the purpose of pam_mount).  So this is most certainly a bug. 

> Now, the second mounting is indeed not expected and I have never seen it
> mounting encrypted fs. I'll try to reproduce, could you attached any of the
> /etc/pam.d/* files you have modified?

If you're seeing the behavior of it not umounting, I'm surprised you haven't seen it mounting over existing mountpoints, as without my patch it does not check for this at all.  I tested via SSH, so every time I logged out and SSH'd back in, it mounted the shares again.

The configuration is...

pam_mount.conf.xml:
<volume sgrp="domain users" fstype="cifs" options="sec=krb5,cruid=%(USER)"
        server="backup" path="classroom" mountpoint="~/Public" />
<volume sgrp="instructors" fstype="cifs" options="sec=krb5,cruid=%(USER)"
        server="backup" path="course"
        mountpoint="~/Private" />

/etc/pam.d/system-auth:
auth        required      pam_env.so
auth        required      pam_mount.so disable_interactive
auth        sufficient    pam_tcb.so shadow nullok prefix=$2a$ count=8
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

account     sufficient    pam_tcb.so shadow
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_warn.so
account     required      pam_permit.so

password    required      pam_cracklib.so try_first_pass retry=3 minlen=4  dcredit=0  ucredit=0
password    sufficient    pam_tcb.so use_authtok shadow write_to=shadow nullok prefix=$2a$ count=8
password    sufficient    pam_sss.so 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    optional      pam_systemd.so
session     optional      pam_mkhomedir.so
session     required      pam_tcb.so
session     optional      pam_sss.so
session     optional      pam_mount.so disable_interactive
session     required      pam_warn.so

Hi there,
I have tried to reproduce and with your /etc/pam.d/system-auth I cannot even mount my volume as I get an authorization denied :) They do not get unmounted neither at logout if I mount them by hand in between.

I am not expert enough in pam-shits.so to know if this is an issue in the ways to call pam_mount from system-auth.

Maybe you could try my config too to see if you get your volumes mounted and unmounted properly?

I am using pam_mount within /etc/pam.d/kdm (I want them mounted only when I am on X) and with this they get mounted an unmounted properly.

#%PAM-1.0
auth       required    pam_env.so
auth       required    pam_succeed_if.so 
auth       optional    pam_mount.so
auth       sufficient  pam_succeed_if.so user ingroup nopasswdlogin
auth       substack    system-auth
-auth      optional    pam_kwallet.so
account    required    pam_nologin.so
account    include     system-auth
password   include     system-auth
session    required    pam_loginuid.so
session    optional    pam_console.so
session    optional    pam_keyinit.so force revoke
session    optional    pam_mount.so
session    required    pam_namespace.so
session    include     system-auth
-session   optional    pam_kwallet.so

Thanks for looking at it.

Since you're doing crypt stuff and not CIFS, disable_interactive won't work for you, since pam_mount needs your password.  For my CIFS mounts, they're using the kerberos ticket generated by the sss authentication, so they don't need another password.

If you change it based on what I have to not have disable_interactive, and add use_first_pass to your auth pam_tcb.so line, it should work for you.

I have to system-auth so that it works via GUI login as well SSH, so the only changes I can make to more closely reflect your config are:
- change auth pam_mount.so line to optional
- move session pam_mount.so line up to just under session pam_keyinit.so line

Neither make any difference.  In fact I just noticed that when I kill all of the user's processes and log in the first time, it mounts the shares twice!  Subsequent logins only mount it once.  My patch still fixes all issues with mounting more than once.

For your situation, unmounting may work if your mounts are done via FUSE.

Hi there,
thank you for the explanations, it worked with use_first_pass (or no) in pam_tcb.

I can confirm the bug now, even with my encrypted filesystem, but *only* if I call pam_mount as you did through system-auth!

If I call pam_mount from kdm (as in comment 3 for instance), then I have no issue, it unmounts when I log out (it is not fuse, just umount). So I am not enterely convinced the issue is due to pam_mount only.

Somehow, when you logout, some credentials are not reset properly with system-auth?? I don't have too much idea but I am wondering if this is not related to some sessions remaining open forever (bug https://bugs.mageia.org/show_bug.cgi?id=14627). Could you try to find if you have some funny session around when you login/logout with "loginctl"?

For the other issue, indeed, in any cases, pam_mount was trying to remount over the already mounted filesystem. I'll add your patch for mga6!

(In reply to Chris Denice from comment #5)
> For the other issue, indeed, in any cases, pam_mount was trying to remount
> over the already mounted filesystem. I'll add your patch for mga6!

Thanks, but I *need* this patch for Mageia 5.

lol!

ok, I'll upload it today; if you make an abuse of power to pass this under release critical, you'll have it :)

(In reply to Chris Denice from comment #5)
> I can confirm the bug now, even with my encrypted filesystem, but *only* if
> I call pam_mount as you did through system-auth!
> 
> If I call pam_mount from kdm (as in comment 3 for instance), then I have no
> issue, it unmounts when I log out (it is not fuse, just umount). So I am not
> enterely convinced the issue is due to pam_mount only.

Well it sounds like systemd may be causing the bug one way or another, but it's interesting to hear that it works in some configurations, so it may not be what some people think.  I'm really not sure and I don't know how one would debug this.

It doesn't make much sense that it would work with your configuration but not if it's in system-auth, because the kdm config includes system-auth, so it's getting in there either way.

> Somehow, when you logout, some credentials are not reset properly with
> system-auth?? I don't have too much idea but I am wondering if this is not
> related to some sessions remaining open forever (bug
> https://bugs.mageia.org/show_bug.cgi?id=14627). Could you try to find if you
> have some funny session around when you login/logout with "loginctl"?

It's not a funny session, but of course loginctl still shows a session, because gpg-agent is still running.  That's normal.  Even if I kill gpg-agent, which ends the systemd login session, it still doesn't umount the cifs shares.

(In reply to Chris Denice from comment #7)
> lol!
> 
> ok, I'll upload it today; if you make an abuse of power to pass this under
> release critical, you'll have it :)

It certainly is critical for me; I can't use Mageia 5 at work without this patch.  Anyway, it shouldn't cause any regressions, so no reason not to get it in now.

Are you going to add hxtools too, or save that for mga6?

(In reply to Chris Denice from comment #5)
> If I call pam_mount from kdm (as in comment 3 for instance), then I have no
> issue, it unmounts when I log out (it is not fuse, just umount). So I am not
> enterely convinced the issue is due to pam_mount only.

Have you tried testing via SSH to see what happens with that?

hxtools is on my todo list, but I don't think I'll have time for mga5.
I did not try through ssh, I will.

(In reply to Chris Denice from comment #11)
> hxtools is on my todo list, but I don't think I'll have time for mga5.

OK, that's fine.  I think it can help with the issue of things not being umounted in some cases, but it doesn't fix my issue anyway.  Note that I did actually import it into SVN though, so it won't be much work for you once you do get to it (maybe just re-syncing it with Fedora if they've updated it again by then) and adding the Requires/Recommends to pam_mount.

(In reply to Chris Denice from comment #11)
> I did not try through ssh, I will.

Thanks for your help with this.  I really appreciate it.

No pb. Your patch actually breaks my system :)

I am mounting with pam_mount two directories: "a" and "b" like this:

/a
/a/b

and with the patch I get a message saying that one is already mounted when I tried. Please, post a new patch, and I'll test again and update.

--

Otherwise, ssh login asked me my pam_mount passwd, but does not mount the directories afterwards. Other weird stuff, the unmounting seems to work after a fresh boot and first login and first logout. After, it is back to the buggy behaviour.

Created attachment 6157 [details]
updated patch that supports top-level directories

Try this one.

thanks!
Package committed and freeze push requested.

Added Colin in cc, it may have an idea wrt systemd interaction (when the mga5 stormfest will be over)

CC: (none) => mageia

To David,
I have sync hxtools on the svn repos; tested it on chroot. I don't think it is reasonable to push it for mga5; but you may test it already for your own purpose. You'll find osl in hxtools-system.
cheers.

Thanks.  Yeah, I was thinking we could push hxtools once Cauldron reopens.  It won't make a difference for me unless we can get unmounting working, but it'll be good to have it for those that can.

Is this bug fixed since a freeze push was requested?

Keywords: (none) => NEEDINFO

No.  I'll say more about this next week.

I had set this up Friday on another machine here and one time I was able to log out and it actually unmounted things and removed the mount points, but now I can't reproduce that.  Still won't unmount.  At least my patch works :D

Hi David,
I see you have updated pam_mount to the latest recently, did it fix this bug as well?

I don't know, as I have changed jobs and am not using the systems where I found this problem.  Hopefully I can set up something to test this at some point.  I eas disappointed that my patch wasn't upstreamed.

Should we simply set this resolved old,
or can it be tested on current versions?

CC: (none) => fri

It can still be tested, details are toward the top.  I don't know why upstream doesn't check their bug reports.

I see that 2.18 is out, I'll import it.

Mageia 5 is EOL
Feel free to reopen if is still valid in pam_mount-2.19-1.mga9

Resolution: (none) => OLD
Status: NEW => RESOLVED