I am trying out pam_mount on Cauldron and have it configured to mount some CIFS shares using the user's krb5 credentials to subdirs in the user's home directory. Mounting works just fine, but when I log out, it fails to unmount them, and doesn't log anything of interest to help diagnose the problem. Some Googling suggests that pam_systemd.so drops the privileges it needs to do the umount and that's why it doesn't work, but I don't know if this is true. As if that's not bad enough, when you log in again, it remounts over the existing active mount point. If it would at least not do that, the first problem wouldn't be a big problem. So, I filed a request upstream about that, including a patch: https://sourceforge.net/p/pam-mount/feature-requests/29/ As a side note, pam_mount can also use a tool to find if any processes are using any files inside of the mount point when logging out and kill those processes, which could help it with umounting if the ability to do that is ever fixed (and it may be desirable regardless). For some unknown reason, they don't use lsof for this, they use a tool called ofl, which comes from the hxtools package, which we don't have. I imported it from Fedora into our SVN and adapated it for Mageia (it isn't built yet). Our pam_mount package should require or at least recommend it. Reproducible: Steps to Reproduce:
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.
Keywords: NEEDINFO => (none)Whiteboard: (none) => MGA5TOO
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) => OLDStatus: NEW => RESOLVED