Source: linux Version: 4.14~rc7-1~exp1 Severity: important Control: affects -1 cifs-utils Control: affects -1 linux-image-amd64 Control: found -1 4.13.4-2 Control: notfound -1 4.12.6-1
When using multiuser cifs on domain members with Kerberos authorization, user accesses to mounted file systems fail with the message "File name too long" even when the path is short. This is a regression since 4.12.6-1 (the kernel included in buster D-I alpha-1). == Scenario and expectations == This is on a Linux server previously joined to a Windows Active Directory domain with realmd such that users may authenticate against the KDC via pam_sss.so, and are issued Kerberos tickets for their session which can also be used for authorizing file system access on the domain's file servers. I expect multiuser CIFS mounts done as root with machine credentials from the default krb5.keytab to a) not prompt for a password, and b) to be reusable by unprivileged users such that files appear to be owned by the user doing the file access. This is a *very* nice scenario on a large Windows domain, and it has been supported by cifs for ages. The relevant flags to mount.cifs are "multiuser,sec=krb5,user=MACHINE$@KRB5.DOMAIN.NAME". Any machine principal listed in the output of "klist -k /etc/krb5.keytab" will do for the initial connection: these are the ones that were stashed away by "realm add" when the Linux machine was added to the AD domain. The mounts work fine in affected kernels, it's the upcall-based multiuser part that's breaking. However, changing the kernel version alone is sufficient to provoke it consistently. == Affected version 4.14~rc7-1~exp1 == root@calamari:~# uname -a Linux calamari 4.14.0-rc7-amd64 #1 SMP Debian 4.14~rc7-1~exp1 (2017-10-30) x86_64 GNU/Linux root@calamari:~# mount.cifs //SERVER1/Temporary /t -o user='CALAMARI$@DOM.AIN',multiuser,vers=3.0,sec=krb5,dom=DOM andrewtc@calamari:~$ touch /t/AndrewTC/file.$$ touch: cannot touch '/t/AndrewTC/file.646': File name too long andrewtc@calamari:~$ dir /t/AndrewTC/dir.$$ dir: cannot access '/t/AndrewTC/dir.646': File name too long andrewtc@calamari:~$ ls -la /t/AndrewTC total 12 drwxr-xr-x 2 andrewtc domain users 4096 Nov 1 12:47 . drwxr-xr-x 2 andrewtc domain users 8192 Nov 1 10:26 .. Files created by others can oddly be removed. Directory, if listable, is cd'able. Same message with a "touch foo" afterwards, and no file is created. The ability to list and chdir into a directory may or may not not be consistently available: I recall not being able to, but perhaps with a different set of flags or a different kernel. Sorry about the poor note-keeping. == Affected version 4.13.4-2 == root@calamari:~# uname -a Linux calamari 4.13.0-1-amd64 #1 SMP Debian 4.13.4-2 (2017-10-15) x86_64 GNU/Linux root@calamari:~# mount.cifs //SERVER1/Temporary /t -o user='CALAMARI$@DOM.AIN',multiuser,vers=3.0,sec=krb5,dom=DOM andrewtc@calamari:~$ ls -la /t/AndrewTC ls: cannot access '/t/AndrewTC': File name too long andrewtc@calamari:~$ touch /t/AndrewTC/file.$$ touch: cannot touch '/t/AndrewTC/file.567': File name too long andrewtc@calamari:~$ mkdir /t/AndrewTC/dir.$$ mkdir: cannot create directory ‘/t/AndrewTC/dir.567’: File name too long == Unaffected version 4.12.6-1 == root@calamari:~# uname -a Linux calamari 4.12.0-1-amd64 #1 SMP Debian 4.12.6-1 (2017-08-12) x86_64 GNU/Linux root@calamari:~# mount.cifs //SERVER1/Temporary /t -o user='CALAMARI$@DOM.AIN',multiuser,vers=3.0,sec=krb5,dom=DOM andrewtc@calamari:~$ touch /t/AndrewTC/file.$$ andrewtc@calamari:~$ mkdir /t/AndrewTC/dir.$$ andrewtc@calamari:~$ ls -la /t/AndrewTC total 12 drwxr-xr-x 2 andrewtc domain users 4096 Nov 1 12:35 . drwxr-xr-x 2 andrewtc domain users 8192 Nov 1 10:26 .. drwxr-xr-x 2 andrewtc domain users 0 Nov 1 12:35 dir.566 -rwxr-xr-x 1 andrewtc domain users 0 Nov 1 12:35 file.566 Everything's fine here, and files can be accessed/edited/deleted perfectly normally. == Observations == The following non-multiuser mounts allow the user normal file access on 4.14.0-rc7, and might be suitable as workarounds for some folks. Also these prove that the fault is limited to use of the multiuser flag for krb5 setups at least (but maybe other auth types too). # mount.cifs //SERVER1/Temporary /t -o user=andrewtc,vers=3.0,dom=DOM,uid=andrewtc Password for andrewtc@//SERVER1/Temporary: ********* ;; "Mount on the user's behalf as root, and type in their password" # kinit -p andrewtc Password for andre...@dom.ain: # mount.cifs //SERVER1/Temporary /t -o user=andrewtc,vers=3.0,dom=DOM,sec=krb5,uid=andrewtc ;; "Get a Kerberos ticket as the user's principal, and authorize using that right now." There's nothing fancy about this mount: it's a plain old share from a Windows Server 2012R2 box. No DFS weirdness or file system permissions that would prevent the unprivileged user or the machine from seeing or doing anything in that directory. Root itself does not have any Kerberos identity upon first login in this setup. Some relevant upstream commits: U1. https://github.com/torvalds/linux/commit/d3edede29f74d335f81d95a4588f5f136a9f7dcf - might have introduced the regression. U2. https://github.com/torvalds/linux/commit/6e3c1529c39e92ed64ca41d53abadabbaa1d5393 - I had hoped this might fix it. No dice :( I'm using cifs-utils 2:6.7-1. The unaffected kernel above is the one included in D-I alpha1 for buster. If anyone needs to revert, a .deb is available inside the iso-cd netinst images under https://cdimage.debian.org/cdimage/buster_di_alpha1/ -- Andrew Chadwick