pam_mount does not mount the volumes that contain defined control attributes (user, pgrp, sgrp, uid, and gid)

[Eduardo Santos de Moraes]

The pam_mount module does not mount the volumes that contain defined control attributes (user, pgrp, sgrp, uid, and gid).

I believe that it simply ignores all volume tags that contain this control, because even with debug enable ="1" nothing is registered in syslog. Only volumes that are defined without any type of control attribute work and produce information in the log.

Example:

It works:

 <volume fstype="cifs" server="FILESERVER" path="SHARE$" mountpoint="~/SHARE" options="gid=MYGROUP,file_mode=0770,dir_mode=0770" />

It does not work:

 <volume sgrp="MYGROUP" fstype="cifs" server="FILESERVER" path="SHARE$" mountpoint="~/SHARE" options="gid=MYGROUP,file_mode=0770,dir_mode=0770" />

It has been tested in the following environments:

* Ubuntu 18.04.2 LTS
* libpam-mount 2.16-3ubuntu0.1

* Ubuntu 19.04
* libpam-mount:amd64 2.16-9ubuntu2

[Paride Legovini (paride)]

Thank you for taking the time to file a report and helping to make Ubuntu better. It is not clear to me how samba is involved in this issue; could you please add some more context?

More in general, there isn't really enough information here for a developer to confirm this issue is a bug, or to begin working on it, so I am marking this bug Incomplete for now. We'd be grateful if you would provide a more complete description of the problem and then change the bug status back to New. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html.

Thank you!

[Eduardo Santos de Moraes (emoraes25)]

Excuse me!
I opened the bug in the wrong place. Actually it's about the libpam-mount package and not Samba. Anyway, thank you for your attention!

[Christian Ehrhardt  (paelzer)]

Dupped the latter bug and copied the extra info from there

[Christian Ehrhardt  (paelzer)]

I took a clean VM (Bionic)
And set things up

$ sudo apt install libpam-mount
$ sudo mkdir /mnt/foo
$ sudo fallocate -l 10M /mnt/foo.img
$ sudo mkfs.ext4 /mnt/foo.img

Add the volume config:
<volume user="ubuntu" path="/mnt/foo.img" mountpoint="/mnt/foo" fstype="ext4" />

# Enable ssh login for user ubuntu and another user in my case "notubuntu"
$ id ubuntu
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(lxd),114(netdev)
ubuntu@bionic-ipvsadm:~$ id notubuntu
uid=1002(notubuntu) gid=1002(notubuntu) groups=1002(notubuntu)

So I could also use grp sudo and such later on.

Logging in as ubuntu gives me
ubuntu@bionic-ipvsadm:~$ mount | grep foo
/mnt/foo.img on /mnt/foo type ext4 (rw,relatime,data=ordered)

Logging in as "notubuntu" does not mount the device.

ALl as it should be right?
Now checking this volume definition:
  <volume sgrp="sudo" path="/mnt/foo.img" mountpoint="/mnt/foo" fstype="ext4" />

Still working to mount when "ubuntu" logs in (being member of sudo) and not mounting when "notubuntu" logs in.

Could you show us
$ id <yourusername>
If it even is a member of group "MYGROUP"
That pretty much sounds like a samba group which isn't what pam checks.
It checks the local systems group membership.

[Eduardo Santos de Moraes (emoraes25)]

I am really working in an Active Directory environment and using Samba with Winbind on my Linux systems to have the users and groups of my domain recognized. However this always worked for me in pam_mount. See the comparison of same configuration on a computer with Ubuntu 16.04 and another with Ubuntu 18.04 in my environment. The example with "MYGROUP" was hypothetical. My real scenario is as follows:

Outputs in Ubuntu 16.04 and libpam-mount 2.14-1.1:

eduardo.moraes@URU0095285LVM03:~$ grep NGTI /etc/security/pam_mount.conf.xml
 <volume sgrp="NGTI" fstype="cifs" server="sca01uru" path="NGTI$" mountpoint="~/NGTI" options="gid=NGTI,iocharset=utf8,file_mode=0770,dir_mode=0770" />
 <volume sgrp="NGTI" fstype="cifs" server="sca01uru" path="SCAN_NGTI$" mountpoint="~/SCAN_NGTI" options="gid=NGTI,iocharset=utf8,file_mode=0770,dir_mode=0770" />

eduardo.moraes@URU0095285LVM03:~$ id
uid=111141(eduardo.moraes) gid=110513(usuários do domínio) groups=110513(usuários do domínio),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare),10000(BUILTIN\administrators),10001(BUILTIN\users),110512(admins. do domínio),110572(grupo de replicação de senha rodc negado),111141(eduardo.moraes),111240(adm),111251(ngti),112043(mdd_sra),112047(autenticadores),112756(cfcv)

eduardo.moraes@URU0095285LVM03:~$ mount | grep 'NGTI'
//sca01uru/NGTI$ on /home/eduardo.moraes/NGTI type cifs (rw,relatime,vers=default,cache=strict,username=eduardo.moraes,domain=,uid=111141,forceuid,gid=111251,forcegid,addr=10.120.100.71,file_mode=0770,dir_mode=0770,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)
//sca01uru/SCAN_NGTI$ on /home/eduardo.moraes/SCAN_NGTI type cifs (rw,relatime,vers=default,cache=strict,username=eduardo.moraes,domain=,uid=111141,forceuid,gid=111251,forcegid,addr=10.120.100.71,file_mode=0770,dir_mode=0770,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)

Outputs in Ubuntu 18.04 and libpam-mount 2.16-3ubuntu0.1:

eduardo.moraes@URU0095285LVM02:~$ grep NGTI /etc/security/pam_mount.conf.xml
 <volume sgrp="NGTI" fstype="cifs" server="sca01uru" path="NGTI$" mountpoint="~/NGTI" options="gid=NGTI,iocharset=utf8,file_mode=0770,dir_mode=0770" />
 <volume sgrp="NGTI" fstype="cifs" server="sca01uru" path="SCAN_NGTI$" mountpoint="~/SCAN_NGTI" options="gid=NGTI,iocharset=utf8,file_mode=0770,dir_mode=0770" />

eduardo.moraes@URU0095285LVM02:~$ id
uid=111141(eduardo.moraes) gid=110513(usuários do domínio) groups=110513(usuários do domínio),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),116(lpadmin),126(sambashare),10000(BUILTIN\administrators),10001(BUILTIN\users),110512(admins. do domínio),110572(grupo de replicação de senha rodc negado),111141(eduardo.moraes),111240(adm),111251(ngti),112043(mdd_sra),112047(autenticadores),112756(cfcv)

eduardo.moraes@URU0095285LVM02:~$ mount | grep 'NGTI'
eduardo.moraes@URU0095285LVM02:~$

Although the NGTI group is on the remote base of the AD Domain Controller, the "libnss-winbind" library allows the name service switch (NSS) to availables domain users and groups to the local system. Look:

eduardo.moraes@URU0095285LVM03:~$ getent group ngti
ngti:x:111...

[Christian Ehrhardt  (paelzer)]

Interestnig, now I don't have such a setup to debug that on my own.
A few things I wanted to check thou.

Does your samba/windbind have in /etc/samba/smb.conf:
  winbind expand groups = 1
Your positive getent results suggests this works, but I wanted to be sure.

Further I wanted to ask, did you try with lowercase?
Some parts of pam don't like to differentiate here, maybe that got changed in the update.
  sgrp="ngti"

Further I have seen many forms of sgrp with AD.
I don't know if they makes sense at all, but they might be easy and worth try:
  sgrp="domain ngti"
  sgrp="domain NGTI"
  sgrp="domain ngti@YOURDOMAINURL"
  sgrp="YOUDOMAINNAME\ngti^group"
  sgrp="YOUDOMAINNAME\ngti"

Finally, you might try to isolate it we are really looking at a samba/windbing/libpam_mount/... issue.
You could create a new system (16.04) and set it up to work.
Then you could try to upgrade those components individually.
To do so replace xenial with bionic in /etc/apt/sources.list, run `apt update`.
And then instead of a full upgrade try if you e.g. can `apt install libpam_mount` which will drag some new dependencies without upgrading too much else e.g. no samba. Test with that and we know if it actually is in libpam_mount or maybe in another component.
You can do the same for samba/windbind or *pam in general.
Note: This is just for debugging and not generally recommended.

Not sure I can help, but let me know what you find maybe we can find something together.

[Eduardo Santos de Moraes (emoraes25)]

Yes! In fact my smb.conf is configured with: "winbind expand groups = 1". But your suggestion to configure sgrp="ngti" worked!

However, pam_mount seems to ignore the icase="yes/no" attribute. It seems to me that icase="yes" was the standard before. Now in "man pam_mount.conf(5)" says that icase="no" is the default. I tried both ways while keeping "NGTI" in the uppercase and it did not work. Even more strange is the fact that I tried gid="11125" (which theoretically does not depend on icase), but it did not work either.

Anyway, what matters is that it's working now, and I'm very grateful for all of your help!

Thanks to you I can give a positive feedback to the appraisers of my CID Project (https://c-i-d.sourceforge.io). I not to imagined that it was something so simple! Lol

Hug!

[Christian Ehrhardt  (paelzer)]

Glad I could help - especially since I'm really not an expert in this particular area.
It seems I was just your rubber duck to talk to :-)

I'll leave the bug open, but at low prio for the icase issue.

TBH if you could afford the time this is soemthing I'd ask you to report upstream [1] and mention the created bug link here then. To my knowledge there is no Ubuntu/Debian Delta that would affect it. But before doing so maybe experiment some more with icase/regex combinations.

[1]: https://sourceforge.net/p/pam-mount/_list/tickets?source=navbar

[Eduardo Santos de Moraes (emoraes25)]

Yes my friend! Make sure that you have helped me a lot, not only for your knowledge, but mainly for your goodwill and interest.

I logged the bug upstream. Follow the link: https://sourceforge.net/p/pam-mount/bugs/126/

Thank you so much again!