Considerations for the SRU team:
I confirmed that the behavior in Jammy is different than
Focal and Mantic, the previous / next supported releases.
(Steps in the next comment.)
So, although this SRU changes behavior in a stable release
(generally not OK in SRUs), it is actually Jammy that changed
behavior _across_ stable releases (and to a buggy one!).
Thus, the SRU is reasonably _restoring_ (arguably, _fixing_)
the _expected_ behavior. So, this looks OK for SRU, IMHO.
Additionally, I considered two points before sponsoring this.
1) The impact of the code changes to non-autofs/non-automount:
And it seems virtually zero, considering the man pages explain
the flag now used in statx() is used in other related syscalls
(stat, lstat, fstatat), which have it implied since Linux 4.11.
And it indeed only affects automount (note the flag name).
So, even though this change is "new" in Jammy, it's been tested
in older and later releases for a long time (pre-Bionic kernels).
stat(2):
AT_NO_AUTOMOUNT (since Linux 2.6.38)
[...] Since Linux 4.11 this flag is implied.
statx(2):
AT_NO_AUTOMOUNT
[...]
All of stat(2), lstat(2), and fstatat(2) act as though
AT_NO_AUTOMOUNT
was set.
2) Whether users may have started to rely on this behavior
I agree this is unlikely, and think so because of 3 points:
2.1) This behavior did not exist in previous releases,
which reduces the chances it has been 'learned' before.
2.2) The usage of autofs/automount rely on access to be made
_to a particular mountpoint_ in order for it to be _mounted_.
This is reflected in different documentation sources online,
so it is likely that this is the way that has been 'learned'.
2.3) The safe side is, _even if_ an user started to rely on
this behavior to automount the subdirs, the very next thing
they will do (if they actually need that subdir mounted) is
to _access_ that subdir - which can mount it just as before!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/2033892
Title:
ls -l triggers mount of autofs shares when --ghost option is present
or browse_mode is enabled
Status in coreutils package in Ubuntu:
Fix Released
Status in coreutils source package in Jammy:
In Progress
Status in coreutils package in Fedora:
Fix Released
Bug description:
[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 <rsa...@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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
