CIFS option 'cruid' does not appear to work properly with 'multiuser' and 'vers=1.0'
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cifs-utils (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
I'm trying to set up a CIFS mount with 'cruid' and 'multiuser' so I can use autofs, and 'vers=1.0' so I can use unix extensions. The samba server uses kerberos tickets for authentication.
When I try to run the mount, it appears to ignore the cruid flag and instead check root's kerberos ticket cache. If I use 'vers=2.0' instead of 1.0, the mount works as expected, but I lose the unix extensions. Nothing that I can find in the documentation indicates that I shouldn't be able to use these flags together.
Failed session example: Note that the upcall is checking creduid=0, when I'm asking it to use 1000
root@syllepsis:~# mount //hostname/users /mnt/test -v -omultiuser,
mount.cifs kernel mount options: ip=192.
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs
Oct 22 13:59:00 syllepsis cifs.upcall: key description: cifs.spnego;
Oct 22 13:59:00 syllepsis cifs.upcall: ver=2
Oct 22 13:59:00 syllepsis cifs.upcall: host=hostname
Oct 22 13:59:00 syllepsis cifs.upcall: ip=192.168.0.10
Oct 22 13:59:00 syllepsis cifs.upcall: sec=1
Oct 22 13:59:00 syllepsis cifs.upcall: uid=0
Oct 22 13:59:00 syllepsis cifs.upcall: creduid=0
Oct 22 13:59:00 syllepsis cifs.upcall: pid=3531
Oct 22 13:59:00 syllepsis cifs.upcall: get_cachename_
Oct 22 13:59:00 syllepsis cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_0
Oct 22 13:59:00 syllepsis cifs.upcall: get_tgt_time: unable to get principal
Oct 22 13:59:00 syllepsis cifs.upcall: Exit status 1
Oct 22 13:59:00 syllepsis kernel: [61476.071633] CIFS VFS: Send error in SessSetup = -126
Oct 22 13:59:00 syllepsis kernel: [61476.071648] CIFS VFS: cifs_read_super: get root inode failed
Successful Session with smb version 2.0:
root@syllepsis:~# mount //hostname/users /mnt/test -v -omultiuser,
mount.cifs kernel mount options: ip=192.
Oct 22 14:00:44 syllepsis cifs.upcall: key description: cifs.spnego;
Oct 22 14:00:44 syllepsis cifs.upcall: ver=2
Oct 22 14:00:44 syllepsis cifs.upcall: host=hostname
Oct 22 14:00:44 syllepsis cifs.upcall: ip=192.168.0.10
Oct 22 14:00:44 syllepsis cifs.upcall: sec=1
Oct 22 14:00:44 syllepsis cifs.upcall: uid=0
Oct 22 14:00:44 syllepsis cifs.upcall: creduid=1000
Oct 22 14:00:44 syllepsis cifs.upcall: user=root
Oct 22 14:00:44 syllepsis cifs.upcall: pid=3872
Oct 22 14:00:44 syllepsis cifs.upcall: get_cachename_
Oct 22 14:00:44 syllepsis cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/
Oct 22 14:00:44 syllepsis cifs.upcall: handle_krb5_mech: getting service ticket for hostname
Oct 22 14:00:44 syllepsis cifs.upcall: handle_krb5_mech: obtained service ticket
Oct 22 14:00:44 syllepsis cifs.upcall: Exit status 0
System information:
lsb_release -rd
Description: Ubuntu 18.04.1 LTS
Release: 18.04
uname -a
Linux syllepsis 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
mount.cifs -V
mount.cifs version: 6.8
apt-cache policy cifs-utils
cifs-utils:
Installed: 2:6.8-1
Candidate: 2:6.8-1
Version table:
*** 2:6.8-1 500
500 http://
100 /var/lib/
I have the same issue. Here is a related RedHat bug. It seems they fixed it, twice, and pushed two? patches upstream. The first attempt got merged, but their second more complete patch (that seems to address this scenario) seems to have gone missing.
In my case, the KRB5CCNAME variable in the user's calling process is not available, presumably due to the autofs intermediary?
Thus the environment scraping for the KRB5CCNAME fails, and as the ticket's filename has a random session specific suffix added to its filename, it cannot be found by cifs.upcall.
i.e, due to GSSAPI authentication via sshd, the ticket's filename is: KRB5CCNAME= FILE:/tmp/ krb5cc_ 1001_XXXX9aLKwo . However, it is expected to be: FILE:/tmp/ krb5cc_ 1001
Here is the RedHat bug report: https:/ /bugzilla. redhat. com/show_ bug.cgi? id=517195
Edited: While following up, I realized that while the RedHat bug's commentary implies there was a later, more complete fix, I could not find any such patch attached to that bug report.