Bug#880504: multiuser cifs: spurious ETOOLONG, file writes & dir reads broken since 4.12.6 [message: "File name too long"]
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 andrewtc@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
Reply to: