| 2024-02-12 22:17:05 |
Matthew Ruffell |
description |
Release: 22.04.3 LTS
coreutils 8.32-4.1ubuntu1
ls triggers unwanted mounts of autofs filesystems
cause: coreutils 8.32.4.1ubuntu1 uses statx which not pass the AT_NO_AUTOMOUNT flag
This bug is also known (and fixed) at Redhat https://bugzilla.redhat.com/show_bug.cgi?id=2044981
upstream commits:
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-178-g92cb8427c53
fedora commit https://src.fedoraproject.org/rpms/coreutils/c/d736cafa20f13eeb037a3950bdbb4b63dc39b7e3?branch=f35 |
[Impact]
Issuing a 'ls -l' or a 'stat' on an autofs share when you have set --ghost in the auto.master file, or browse_mode=yes in autofs.conf will lead to the shares being mounted, when they didn't previously.
Disks / shares may not be present and the mounts may fail, leading to errors in your output.
This is a behaviour change in autofs 8.32, which occurred in the transition to using statx() instead of stat()/lstat() in previous releases.
There doesn't seem to be any workarounds, apart from not running a 'ls -l' in your autofs share directory.
[Testcase]
Start two Jammy VMs. One will be a NFS server, the other, the client.
NFS server:
Server VM:
$ sudo hostnamectl set-hostname jammy-nfs-server
$ sudo apt update && sudo apt upgrade -y
$ sudo apt install nfs-kernel-server
$ sudo mkdir /export
$ sudo mkdir /export/users
$ sudo vi /etc/exports # add the following lines:
/export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync)
/export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync)
$ sudo systemctl restart nfs-server.service
AutoFS Client:
$ sudo apt update
$ sudo apt install autofs
$ sudo vim /etc/autofs.conf
browse_mode = yes
$ sudo mkdir /mnt2
$ sudo vim /etc/auto.master
/mnt2 /etc/auto.indirect
$ sudo vim /etc/auto.indirect
export 192.168.122.18:/export
export-missing 192.168.122.18:/export-missing
$ sudo reboot
$ cd /mnt2
$ ls -l
ls: cannot access 'export-missing': No such file or directory
total 4
drwxr-xr-x 3 root root 4096 Feb 12 21:48 export
d????????? ? ? ? ? ? export-missing
$ mount -l | grep /mnt2
/etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561)
192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18)
We see the mount for export occurred, and export-missing was attempted, but it was either bogus or the disk was not present, leading to a "No such file or directory" error.
There are test packages available in the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test
If you install them, this is what should occur:
$ ls -l
total 0
drwxr-xr-x 2 root root 0 Feb 12 22:01 export
drwxr-xr-x 2 root root 0 Feb 12 22:01 export-missing
$ mount -l | grep /mnt2
/etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346)
No mounts happen, and no errors either.
[Where problems could occur]
We are changing the behaviour of core utilities, ls and stat, such that they no longer attempt to mount autofs shares when --ghost option is present or browse_mode is enabled.
This is the intended behaviour in the first place, and has been this way for at least a decade prior, and was changed to return to this behaviour shortly after the release of coreutils that introduced statx() that caused automounts to occur.
It is unlikely any system administrators are relying on the behaviour found in jammy in any scripts or day to day operations that would be adversely affected by the change. The worst case scenario is that a user doing an 'ls -l' on an unmounted disk finds the mount doesn't automatically occur, and they have to attach the disk and issue the mount themselves.
If a regression were to occur, it would be limited to the ls and stat commands, specifically when listing directories linked to autofs mountpoints.
[Other info]
The automount behaviour change was introduced upstream in version 8.32, with the introduction of the statx() call. This means only Jammy is affected.
It was quickly reverted back to how it was originally in version 9.1, which is already available in Mantic and onward.
The commits that solve the issue are:
commit 85c975df2c25bd799370b04bb294e568e001102f
From: Rohan Sable <rsable@redhat.com>
Date: Mon, 7 Mar 2022 14:14:13 +0000
Subject: ls: avoid triggering automounts
Link: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2
commit 92cb8427c537f37edd43c5cef1909585201372ab
From: Pádraig Brady <P@draigBrady.com>
Date: Mon, 7 Mar 2022 23:29:20 +0000
Subject: stat: only automount with --cached=never
Link: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-178-g92cb8427c53
Upstream bugs:
https://bugs.gnu.org/54286
https://bugs.gnu.org/54287 |
|
