regression: with linux-image-4.4.0-38-generic autofs tries to acess folders as root instead of the user

[Robert Euhus]

Running with linux-image-4.4.0-38-generic autofs is not working properly anymore: when I try to access a autofs-monitored folder as normal user "joe" the environment variable $AUTOFS_USER inside the auto mounter map script is set to "root" instead of the user "joe".

A little background information: in our setup the autofs master map /etc/auto.master contains a line:

/mnt/cifs /etc/auto.cifs-shares --timeout=300 --verbose

The script /etc/auto.cifs-shares contains for debugging purposes the lines:

DEBUG=true
$DEBUG && logger -p debug -- "$0: running 'env|grep AUTOFS':"
$DEBUG && logger -p debug -- "$(env|grep AUTOFS)"

and

if test "$1" = "$AUTOFS_USER" ; then
        ## First generate automount map
[..]
else
        logger -p debug -- "$0: Error: User '$AUTOFS_USER' tried to access wrong directory '$1'"
fi

Which yields to the following errors in the logs:

Sep 29 17:03:20 pcXXXXXX root[7613]: AUTOFS_SHOST=pc203re3
                                     AUTOFS_HOME=/root
                                     AUTOFS_GID=0
                                     AUTOFS_UID=0
                                     AUTOFS_GROUP=root
                                     AUTOFS_USER=root
Sep 29 17:03:20 pcXXXXXX root[7614]: /etc/auto.cifs-shares: Error: User 'root' tried to access wrong directory 'joe'
Sep 29 17:03:20 pcXXXXXX automount[7557]: lookup(program): lookup for joe failed
Sep 29 17:03:20 pcXXXXXX automount[7557]: failed to mount /mnt/cifs/joe

So for some reason autofs with this kernel gets the environment variables wrong.
Running an older Kernel like linux-image-4.4.0-36-generic does not show this problem and the cifs shares work as expected.

other Info:
lsb_release -rd
Description: Ubuntu 16.04.1 LTS
Release: 16.04

uname -r
4.4.0-38-generic

If you need any further info or testing, please let me know.

Thanks,
Robert Euhus

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux-image-4.4.0-38-generic 4.4.0-38.57
ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19
Uname: Linux 4.4.0-38-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: euhus 1711 F.... pulseaudio
CurrentDesktop: GNOME
Date: Fri Sep 30 09:36:31 2016
HibernationDevice: RESUME=UUID=1aae5293-ed3d-4dae-a8b5-54d831262f4a
IwConfig:
 lo no wireless extensions.

 enp0s31f6 no wireless extensions.
MachineType: Dell Inc. OptiPlex 5040
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-38-generic root=UUID=adae86bf-dc79-4962-aa5f-41a1a037c8ec ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-38-generic N/A
 linux-backports-modules-4.4.0-38-generic N/A
 linux-firmware 1.157.3
RfKill:
 0: hci0: Bluetooth
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/15/2016
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.2.7
dmi.board.name: 0R790T
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.2.7:bd01/15/2016:svnDellInc.:pnOptiPlex5040:pvr:rvnDellInc.:rn0R790T:rvrA00:cvnDellInc.:ct3:cvr:
dmi.product.name: OptiPlex 5040
dmi.sys.vendor: Dell Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.8 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8

[Robert Euhus (euhus-liste1)]

Hi Joseph,

yes, the problem started directly after the recent upgrade to linux-image-4.4.0-38-generic. I have never encountered this bug before, I know for certain that 4.4.0-36 works fine (as I have said before). Versions 4.4.0-34 and 4.4.0-22 are also without a problem.

The mainline kernel shows the same problem; I have tried:
linux-image-4.8.0-040800-generic_4.8.0-040800.201610022031_amd64.deb
v4.8 (c8d2bc9bc39ebea8437fd974fdbc21847bb897a3)

To me it looks like this bug was introduced between 4.4.0-36 and 4.4.0-38. I will try bisecting these versions following the instructions in the Wiki.

Regards,
Robert

[Joseph Salisbury (jsalisbury)]

Thanks for the update, Robert. Just let me know if you need assistance with the bisect, and I can build the kernels for you.

[Robert Euhus (euhus-liste1)]

Thanks for the offer Joseph! I have read your answer a bit late, so I am already on my 9th kernel (all good so far). The docs were quite good and I have wanted to try out "that bisect thing" for quite a while :)

(It's just a bit annoying that it takes about half an hour to compile on a i5-6500 with 16G RAM. I had expected a bit less.)

But now I have run into the problem, that I cannot build the current bisect point.

I have cloned the kernel repo via
git clone git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git

I have attached the git bisect log up to the current point.

When the compile is just about to be finished it fails with:

EE: 36 symbols changed hash and weren't ignored
II: Module hash change summary...
    vmlinux : 36
II: Done
debian/rules.d/4-checks.mk:3: die Regel für Ziel „abi-check-generic“ scheiterte
make: *** [abi-check-generic] Fehler 1

Sorry it's in German, I can redo it in english. I will attach a longer trace.

I have always compiled doing a clean first:
fakeroot debian/rules clean && fakeroot debian/rules binary-headers binary-generic

So how do I go on from here?

[Tim Gardner (timg-tpi)]

Robert - add ignore files to your ABI directory. For example,

echo 1 > debian.master/abi/4.4.0-41.61/amd64/ignore
echo 1 > debian.master/abi/4.4.0-41.61/amd64/ignore.modules

[Robert Euhus (euhus-liste1)]

Tim - thanks for that advice!

Now I'm finally there:

git bisect good
ca6fe3344554d31ac9c0f7e2e6be490c2d5d501f is the first bad commit
commit ca6fe3344554d31ac9c0f7e2e6be490c2d5d501f
Author: Eric W. Biederman <email address hidden>
Date: Tue Sep 6 09:32:01 2016 -0500

    fs: Call d_automount with the filesystems creds

    BugLink: http://bugs.launchpad.net/bugs/1612135

    Seth Forshee reported a mount regression in nfs autmounts
    with "fs: Add user namespace member to struct super_block".

    It turns out that the assumption that current->cred is something
    reasonable during mount while necessary to improve support of
    unprivileged mounts is wrong in the automount path.

    To fix the existing filesystems override current->cred with the
    init_cred before calling d_automount and restore current->cred after
    d_automount completes.

    To support unprivileged mounts would require a more nuanced cred
    selection, so fail on unprivileged mounts for the time being. As none
    of the filesystems that currently set FS_USERNS_MOUNT implement
    d_automount this check is only good for preventing future problems.

    Fixes: 6e4eab577a0c ("fs: Add user namespace member to struct super_block")
    Tested-by: Seth Forshee <email address hidden>
    Signed-off-by: "Eric W. Biederman" <email address hidden>
    (backported from commit aeaa4a79ff6a5ed912b7362f206cf8576fca538b)
    Signed-off-by: Seth Forshee <email address hidden>
    Acked-by: Stefan Bader <email address hidden>
    Acked-by: Colin King <email address hidden>
    Acked-by: Brad Figg <email address hidden>
    Signed-off-by: Tim Gardner <email address hidden>

:040000 040000 3b16a342088c0cfead081f63bc7fe9bed93bcf00 2634a48c59a1c6b313be2d8406644fd9d0e18a60 M fs

[Robert Euhus (euhus-liste1)]

This bug seems like a duplicate of this one filed moments beforem mine: http://bugs.launchpad.net/bugs/1629204

The came to the same conclusion.