Skip to content

libspl/mnttab: follow symlinks when resolving path via statx - #18469

Merged
tonyhutter merged 1 commit into
openzfs:masterfrom
prakashsurya:openzfs/fix-getextmntent-symlink
Apr 28, 2026
Merged

libspl/mnttab: follow symlinks when resolving path via statx#18469
tonyhutter merged 1 commit into
openzfs:masterfrom
prakashsurya:openzfs/fix-getextmntent-symlink

Conversation

@prakashsurya

@prakashsurya prakashsurya commented Apr 27, 2026

Copy link
Copy Markdown
Member

Motivation and Context

getextmntent() in lib/libspl/os/linux/mnttab.c uses statx(2) with
AT_SYMLINK_NOFOLLOW to obtain the mnt_id of the caller-supplied path. When
that path is a symbolic link crossing a mount boundary, AT_SYMLINK_NOFOLLOW
prevents symlink resolution, causing statx to return the mnt_id of the
mount containing the symlink itself rather than the mount the symlink points
into. The subsequent search through /proc/self/mounts then matches the wrong
entry, so zfs list -Ho name <symlink-path> (and anything that calls
zfs_path_to_zhandle()) reports the wrong dataset.

The same function calls stat64() on the same path immediately beforehand, and
stat64() always follows symlinks — so the two calls were inconsistent when the
path was a symlink.

The bug was introduced by 523d9d6 ("Validate mountpoint on path-based unmount
using statx") but was latent because the autoconf check in config/user-statx.m4
omitted #define _GNU_SOURCE when testing for STATX_MNT_ID, so
HAVE_STATX_MNT_ID was never defined and the statx() path was dead code.
It was exposed by 2b930f6 ("config: fix STATX_MNT_ID detection"), which
fixed the autoconf check and activated the broken path for the first time.

Description

Remove AT_SYMLINK_NOFOLLOW from the statx() call on the caller-supplied
path in getextmntent(), so symlinks are followed — consistent with the
stat64() call on the same path in the same function.

The AT_SYMLINK_NOFOLLOW flag is retained in getextmntent_impl(), where
statx() is called on mp->mnt_mountp (a path read from /proc/self/mounts,
always a real directory).

A regression test is added in
tests/functional/cli_user/zfs_list/zfs_list_009_pos.ksh.

How Has This Been Tested?

Verified with a minimal reproducer: created two ZFS datasets, placed a symlink
inside the first pointing into the second, and confirmed that
zfs list -Ho name <symlink> returns the dataset containing the symlink's
target rather than the dataset containing the symlink.

The regression test zfs_list_009_pos was also run via zfs-tests.sh on both
an unpatched build (FAIL) and with this fix applied (PASS).

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Quality assurance (non-breaking change which makes the code more robust against bugs)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
  • Documentation (a change to man pages or other documentation)

Checklist:

Copilot AI review requested due to automatic review settings April 27, 2026 00:51
Copilot AI reviewed Apr 27, 2026
View reviewed changes

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes incorrect dataset resolution for symlink paths on Linux by ensuring getextmntent() follows symlinks when using statx(..., STATX_MNT_ID, ...), aligning statx() behavior with the existing stat64() call and preventing mismatched /proc/self/mounts lookups.

Changes:

  • Remove AT_SYMLINK_NOFOLLOW from the statx() call in getextmntent() so symlinks are resolved when determining mnt_id.
  • Add a regression test validating that zfs list -Ho name <symlink> returns the dataset owning the symlink target when the symlink crosses a mount boundary.
  • Register the new test in the test packaging (Makefile.am) and test runfile (common.run).

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File Description
lib/libspl/os/linux/mnttab.c Makes statx() follow symlinks in getextmntent() to avoid selecting the wrong mount entry when a symlink crosses mount boundaries.
tests/zfs-tests/tests/functional/cli_user/zfs_list/zfs_list_009_pos.ksh Adds coverage for path-to-dataset resolution through a cross-mount symlink.
tests/zfs-tests/tests/Makefile.am Ensures the new test script is distributed/installed with the test suite.
tests/runfiles/common.run Adds the new test to the cli_user/zfs_list test group so it runs in CI.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@prakashsurya prakashsurya mentioned this pull request Apr 27, 2026
Closed
6 of 14 tasks
ixhamza
ixhamza approved these changes Apr 27, 2026
View reviewed changes

@ixhamza ixhamza left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for running this down, LGTM. I believe the new test should be moved to cli_root/ from cli_user/ as it does privileged operations (zfs create/destroy).

@prakashsurya
libspl/mnttab: follow symlinks when resolving path via statx
6c80768 
When the path argument to "zfs list -Ho name <path>" (or any caller of
zfs_path_to_zhandle()) is a symlink that crosses a mount boundary, the
wrong dataset is returned. Instead of returning the dataset that owns
the symlink's target, getextmntent() matches the dataset containing the
symlink itself.

For example, given two ZFS datasets "tank/ds1" and "tank/ds2", and a
symlink "/tank/ds1/link" pointing into "/tank/ds2":

    $ sudo zfs list -Ho name /tank/ds1/link
    tank/ds1

The expected (and previous) behavior is to return "tank/ds2", since the
symlink's target resides in that dataset.

The problem is in getextmntent(), in lib/libspl/os/linux/mnttab.c. That
function calls statx() on the caller-supplied path to obtain its mnt_id
(used to match against the mnt_id of each entry in /proc/self/mounts),
and it passes AT_SYMLINK_NOFOLLOW to that statx() call. As a result,
the mnt_id returned reflects the symlink's location rather than the
symlink target's mount, and the wrong /proc/self/mounts entry is
matched.

The same function also calls stat64() on the caller-supplied path
(used as a fallback when STATX_MNT_ID is not available, and to populate
the statbuf out-parameter). stat64() always follows symlinks, so the
statx() and stat64() calls were inconsistent: one resolved the symlink,
the other didn't. The AT_SYMLINK_NOFOLLOW behavior may be appropriate
when statx() is called on a mount entry from /proc/self/mounts (which
is always a real directory), but it is wrong for caller-supplied paths,
which may be symlinks.

This bug was introduced by 523d9d6 ("Validate mountpoint on
path-based unmount using statx"), which added the STATX_MNT_ID code
path. However, the bug was latent: config/user-statx.m4 omitted
"#define _GNU_SOURCE" when checking for STATX_MNT_ID in <sys/stat.h>,
so HAVE_STATX_MNT_ID was never defined, and the buggy statx() path was
never compiled in. getextmntent() always fell back to the dev_t
comparison via stat64(), which correctly follows symlinks.

The fix to that autoconf check, in 2b930f6 ("config: fix
STATX_MNT_ID detection"), caused HAVE_STATX_MNT_ID to be properly
defined on kernels that support it, activating the broken
AT_SYMLINK_NOFOLLOW path for the first time and exposing the
regression.

The fix is to drop AT_SYMLINK_NOFOLLOW from the statx() call so that
symlinks are followed, matching the behavior of stat64() on the same
path.

Verified with a minimal reproducer: created two ZFS datasets, placed a
symlink inside the first pointing into the second, and confirmed that
"zfs list -Ho name <symlink>" returns the dataset containing the
symlink's target rather than the dataset containing the symlink.

Signed-off-by: Prakash Surya <prakash.surya@perforce.com>
@prakashsurya
prakashsurya force-pushed the openzfs/fix-getextmntent-symlink branch from 3c67eed to 6c80768 Compare April 27, 2026 13:19
@prakashsurya

prakashsurya commented Apr 27, 2026

Copy link
Copy Markdown
Member Author

@ixhamza thank you! applied your suggestion.

@satmandu satmandu mentioned this pull request Apr 28, 2026
Merged
14 tasks
amotin
amotin approved these changes Apr 28, 2026
View reviewed changes

@amotin amotin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering whether the symlinks should be fallowed there in general, but consistency with stat64() case is definitely an argument.

@amotin amotin added the Status: Accepted Ready to integrate (reviewed, tested) label Apr 28, 2026
@satmandu

satmandu commented Apr 28, 2026

Copy link
Copy Markdown
Contributor

I think backports to the 2.4 & 2.3 series (which don't have the mnttab changes) to sit on top of the 2.4.2 patchset #18462 and the 2.3.7 patchset #18451 will be needed, as this doesn't apply cleanly on top of those.

@tonyhutter
tonyhutter merged commit 4acb629 into openzfs:master Apr 28, 2026
24 of 27 checks passed
@tonyhutter

tonyhutter commented Apr 28, 2026

Copy link
Copy Markdown
Contributor

@satmandu I'll try to pull this into the 2.3.7 and 2.4.2 patchsets.

tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request May 4, 2026
@prakashsurya @tonyhutter
libspl/mnttab: follow symlinks when resolving path via statx (openzfs…
0b58f1d 
…#18469)

When the path argument to "zfs list -Ho name <path>" (or any caller of
zfs_path_to_zhandle()) is a symlink that crosses a mount boundary, the
wrong dataset is returned. Instead of returning the dataset that owns
the symlink's target, getextmntent() matches the dataset containing the
symlink itself.

For example, given two ZFS datasets "tank/ds1" and "tank/ds2", and a
symlink "/tank/ds1/link" pointing into "/tank/ds2":

    $ sudo zfs list -Ho name /tank/ds1/link
    tank/ds1

The expected (and previous) behavior is to return "tank/ds2", since the
symlink's target resides in that dataset.

The problem is in getextmntent(), in lib/libspl/os/linux/mnttab.c. That
function calls statx() on the caller-supplied path to obtain its mnt_id
(used to match against the mnt_id of each entry in /proc/self/mounts),
and it passes AT_SYMLINK_NOFOLLOW to that statx() call. As a result,
the mnt_id returned reflects the symlink's location rather than the
symlink target's mount, and the wrong /proc/self/mounts entry is
matched.

The same function also calls stat64() on the caller-supplied path
(used as a fallback when STATX_MNT_ID is not available, and to populate
the statbuf out-parameter). stat64() always follows symlinks, so the
statx() and stat64() calls were inconsistent: one resolved the symlink,
the other didn't. The AT_SYMLINK_NOFOLLOW behavior may be appropriate
when statx() is called on a mount entry from /proc/self/mounts (which
is always a real directory), but it is wrong for caller-supplied paths,
which may be symlinks.

This bug was introduced by 523d9d6 ("Validate mountpoint on
path-based unmount using statx"), which added the STATX_MNT_ID code
path. However, the bug was latent: config/user-statx.m4 omitted
"#define _GNU_SOURCE" when checking for STATX_MNT_ID in <sys/stat.h>,
so HAVE_STATX_MNT_ID was never defined, and the buggy statx() path was
never compiled in. getextmntent() always fell back to the dev_t
comparison via stat64(), which correctly follows symlinks.

The fix to that autoconf check, in 2b930f6 ("config: fix
STATX_MNT_ID detection"), caused HAVE_STATX_MNT_ID to be properly
defined on kernels that support it, activating the broken
AT_SYMLINK_NOFOLLOW path for the first time and exposing the
regression.

The fix is to drop AT_SYMLINK_NOFOLLOW from the statx() call so that
symlinks are followed, matching the behavior of stat64() on the same
path.

Verified with a minimal reproducer: created two ZFS datasets, placed a
symlink inside the first pointing into the second, and confirmed that
"zfs list -Ho name <symlink>" returns the dataset containing the
symlink's target rather than the dataset containing the symlink.

Signed-off-by: Prakash Surya <prakash.surya@perforce.com>
Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Reviewed-by: Mark Maybee <mark.maybee@delphix.com>
Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com>
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request May 4, 2026
@prakashsurya @tonyhutter
libspl/mnttab: follow symlinks when resolving path via statx (openzfs…
37e4e5a 
…#18469)

When the path argument to "zfs list -Ho name <path>" (or any caller of
zfs_path_to_zhandle()) is a symlink that crosses a mount boundary, the
wrong dataset is returned. Instead of returning the dataset that owns
the symlink's target, getextmntent() matches the dataset containing the
symlink itself.

For example, given two ZFS datasets "tank/ds1" and "tank/ds2", and a
symlink "/tank/ds1/link" pointing into "/tank/ds2":

    $ sudo zfs list -Ho name /tank/ds1/link
    tank/ds1

The expected (and previous) behavior is to return "tank/ds2", since the
symlink's target resides in that dataset.

The problem is in getextmntent(), in lib/libspl/os/linux/mnttab.c. That
function calls statx() on the caller-supplied path to obtain its mnt_id
(used to match against the mnt_id of each entry in /proc/self/mounts),
and it passes AT_SYMLINK_NOFOLLOW to that statx() call. As a result,
the mnt_id returned reflects the symlink's location rather than the
symlink target's mount, and the wrong /proc/self/mounts entry is
matched.

The same function also calls stat64() on the caller-supplied path
(used as a fallback when STATX_MNT_ID is not available, and to populate
the statbuf out-parameter). stat64() always follows symlinks, so the
statx() and stat64() calls were inconsistent: one resolved the symlink,
the other didn't. The AT_SYMLINK_NOFOLLOW behavior may be appropriate
when statx() is called on a mount entry from /proc/self/mounts (which
is always a real directory), but it is wrong for caller-supplied paths,
which may be symlinks.

This bug was introduced by 523d9d6 ("Validate mountpoint on
path-based unmount using statx"), which added the STATX_MNT_ID code
path. However, the bug was latent: config/user-statx.m4 omitted
"#define _GNU_SOURCE" when checking for STATX_MNT_ID in <sys/stat.h>,
so HAVE_STATX_MNT_ID was never defined, and the buggy statx() path was
never compiled in. getextmntent() always fell back to the dev_t
comparison via stat64(), which correctly follows symlinks.

The fix to that autoconf check, in 2b930f6 ("config: fix
STATX_MNT_ID detection"), caused HAVE_STATX_MNT_ID to be properly
defined on kernels that support it, activating the broken
AT_SYMLINK_NOFOLLOW path for the first time and exposing the
regression.

The fix is to drop AT_SYMLINK_NOFOLLOW from the statx() call so that
symlinks are followed, matching the behavior of stat64() on the same
path.

Verified with a minimal reproducer: created two ZFS datasets, placed a
symlink inside the first pointing into the second, and confirmed that
"zfs list -Ho name <symlink>" returns the dataset containing the
symlink's target rather than the dataset containing the symlink.

Signed-off-by: Prakash Surya <prakash.surya@perforce.com>
Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Reviewed-by: Mark Maybee <mark.maybee@delphix.com>
Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com>
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request May 6, 2026
@prakashsurya @tonyhutter
libspl/mnttab: follow symlinks when resolving path via statx (openzfs…
34dc510 
…#18469)

When the path argument to "zfs list -Ho name <path>" (or any caller of
zfs_path_to_zhandle()) is a symlink that crosses a mount boundary, the
wrong dataset is returned. Instead of returning the dataset that owns
the symlink's target, getextmntent() matches the dataset containing the
symlink itself.

For example, given two ZFS datasets "tank/ds1" and "tank/ds2", and a
symlink "/tank/ds1/link" pointing into "/tank/ds2":

    $ sudo zfs list -Ho name /tank/ds1/link
    tank/ds1

The expected (and previous) behavior is to return "tank/ds2", since the
symlink's target resides in that dataset.

The problem is in getextmntent(), in lib/libspl/os/linux/mnttab.c. That
function calls statx() on the caller-supplied path to obtain its mnt_id
(used to match against the mnt_id of each entry in /proc/self/mounts),
and it passes AT_SYMLINK_NOFOLLOW to that statx() call. As a result,
the mnt_id returned reflects the symlink's location rather than the
symlink target's mount, and the wrong /proc/self/mounts entry is
matched.

The same function also calls stat64() on the caller-supplied path
(used as a fallback when STATX_MNT_ID is not available, and to populate
the statbuf out-parameter). stat64() always follows symlinks, so the
statx() and stat64() calls were inconsistent: one resolved the symlink,
the other didn't. The AT_SYMLINK_NOFOLLOW behavior may be appropriate
when statx() is called on a mount entry from /proc/self/mounts (which
is always a real directory), but it is wrong for caller-supplied paths,
which may be symlinks.

This bug was introduced by 523d9d6 ("Validate mountpoint on
path-based unmount using statx"), which added the STATX_MNT_ID code
path. However, the bug was latent: config/user-statx.m4 omitted
"#define _GNU_SOURCE" when checking for STATX_MNT_ID in <sys/stat.h>,
so HAVE_STATX_MNT_ID was never defined, and the buggy statx() path was
never compiled in. getextmntent() always fell back to the dev_t
comparison via stat64(), which correctly follows symlinks.

The fix to that autoconf check, in 2b930f6 ("config: fix
STATX_MNT_ID detection"), caused HAVE_STATX_MNT_ID to be properly
defined on kernels that support it, activating the broken
AT_SYMLINK_NOFOLLOW path for the first time and exposing the
regression.

The fix is to drop AT_SYMLINK_NOFOLLOW from the statx() call so that
symlinks are followed, matching the behavior of stat64() on the same
path.

Verified with a minimal reproducer: created two ZFS datasets, placed a
symlink inside the first pointing into the second, and confirmed that
"zfs list -Ho name <symlink>" returns the dataset containing the
symlink's target rather than the dataset containing the symlink.

Signed-off-by: Prakash Surya <prakash.surya@perforce.com>
Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Reviewed-by: Mark Maybee <mark.maybee@delphix.com>
Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com>
@robertericreeves robertericreeves mentioned this pull request May 11, 2026
Closed
Gality369 pushed a commit to Gality369/zfs that referenced this pull request May 12, 2026
@prakashsurya @Gality369
libspl/mnttab: follow symlinks when resolving path via statx (openzfs…
06bb9fe 
…#18469)

When the path argument to "zfs list -Ho name <path>" (or any caller of
zfs_path_to_zhandle()) is a symlink that crosses a mount boundary, the
wrong dataset is returned. Instead of returning the dataset that owns
the symlink's target, getextmntent() matches the dataset containing the
symlink itself.

For example, given two ZFS datasets "tank/ds1" and "tank/ds2", and a
symlink "/tank/ds1/link" pointing into "/tank/ds2":

    $ sudo zfs list -Ho name /tank/ds1/link
    tank/ds1

The expected (and previous) behavior is to return "tank/ds2", since the
symlink's target resides in that dataset.

The problem is in getextmntent(), in lib/libspl/os/linux/mnttab.c. That
function calls statx() on the caller-supplied path to obtain its mnt_id
(used to match against the mnt_id of each entry in /proc/self/mounts),
and it passes AT_SYMLINK_NOFOLLOW to that statx() call. As a result,
the mnt_id returned reflects the symlink's location rather than the
symlink target's mount, and the wrong /proc/self/mounts entry is
matched.

The same function also calls stat64() on the caller-supplied path
(used as a fallback when STATX_MNT_ID is not available, and to populate
the statbuf out-parameter). stat64() always follows symlinks, so the
statx() and stat64() calls were inconsistent: one resolved the symlink,
the other didn't. The AT_SYMLINK_NOFOLLOW behavior may be appropriate
when statx() is called on a mount entry from /proc/self/mounts (which
is always a real directory), but it is wrong for caller-supplied paths,
which may be symlinks.

This bug was introduced by 523d9d6 ("Validate mountpoint on
path-based unmount using statx"), which added the STATX_MNT_ID code
path. However, the bug was latent: config/user-statx.m4 omitted
"#define _GNU_SOURCE" when checking for STATX_MNT_ID in <sys/stat.h>,
so HAVE_STATX_MNT_ID was never defined, and the buggy statx() path was
never compiled in. getextmntent() always fell back to the dev_t
comparison via stat64(), which correctly follows symlinks.

The fix to that autoconf check, in 2b930f6 ("config: fix
STATX_MNT_ID detection"), caused HAVE_STATX_MNT_ID to be properly
defined on kernels that support it, activating the broken
AT_SYMLINK_NOFOLLOW path for the first time and exposing the
regression.

The fix is to drop AT_SYMLINK_NOFOLLOW from the statx() call so that
symlinks are followed, matching the behavior of stat64() on the same
path.

Verified with a minimal reproducer: created two ZFS datasets, placed a
symlink inside the first pointing into the second, and confirmed that
"zfs list -Ho name <symlink>" returns the dataset containing the
symlink's target rather than the dataset containing the symlink.

Signed-off-by: Prakash Surya <prakash.surya@perforce.com>
Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Reviewed-by: Mark Maybee <mark.maybee@delphix.com>
Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com>
lundman pushed a commit to openzfsonosx/openzfs-fork that referenced this pull request Jul 30, 2026
@prakashsurya @lundman
libspl/mnttab: follow symlinks when resolving path via statx (openzfs…
3545537 
…#18469)

When the path argument to "zfs list -Ho name <path>" (or any caller of
zfs_path_to_zhandle()) is a symlink that crosses a mount boundary, the
wrong dataset is returned. Instead of returning the dataset that owns
the symlink's target, getextmntent() matches the dataset containing the
symlink itself.

For example, given two ZFS datasets "tank/ds1" and "tank/ds2", and a
symlink "/tank/ds1/link" pointing into "/tank/ds2":

    $ sudo zfs list -Ho name /tank/ds1/link
    tank/ds1

The expected (and previous) behavior is to return "tank/ds2", since the
symlink's target resides in that dataset.

The problem is in getextmntent(), in lib/libspl/os/linux/mnttab.c. That
function calls statx() on the caller-supplied path to obtain its mnt_id
(used to match against the mnt_id of each entry in /proc/self/mounts),
and it passes AT_SYMLINK_NOFOLLOW to that statx() call. As a result,
the mnt_id returned reflects the symlink's location rather than the
symlink target's mount, and the wrong /proc/self/mounts entry is
matched.

The same function also calls stat64() on the caller-supplied path
(used as a fallback when STATX_MNT_ID is not available, and to populate
the statbuf out-parameter). stat64() always follows symlinks, so the
statx() and stat64() calls were inconsistent: one resolved the symlink,
the other didn't. The AT_SYMLINK_NOFOLLOW behavior may be appropriate
when statx() is called on a mount entry from /proc/self/mounts (which
is always a real directory), but it is wrong for caller-supplied paths,
which may be symlinks.

This bug was introduced by 523d9d6 ("Validate mountpoint on
path-based unmount using statx"), which added the STATX_MNT_ID code
path. However, the bug was latent: config/user-statx.m4 omitted
"#define _GNU_SOURCE" when checking for STATX_MNT_ID in <sys/stat.h>,
so HAVE_STATX_MNT_ID was never defined, and the buggy statx() path was
never compiled in. getextmntent() always fell back to the dev_t
comparison via stat64(), which correctly follows symlinks.

The fix to that autoconf check, in 2b930f6 ("config: fix
STATX_MNT_ID detection"), caused HAVE_STATX_MNT_ID to be properly
defined on kernels that support it, activating the broken
AT_SYMLINK_NOFOLLOW path for the first time and exposing the
regression.

The fix is to drop AT_SYMLINK_NOFOLLOW from the statx() call so that
symlinks are followed, matching the behavior of stat64() on the same
path.

Verified with a minimal reproducer: created two ZFS datasets, placed a
symlink inside the first pointing into the second, and confirmed that
"zfs list -Ho name <symlink>" returns the dataset containing the
symlink's target rather than the dataset containing the symlink.

Signed-off-by: Prakash Surya <prakash.surya@perforce.com>
Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Reviewed-by: Mark Maybee <mark.maybee@delphix.com>
Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com>
pull Bot pushed a commit to A-Archives-and-Forks/openzfs that referenced this pull request Sep 26, 2026
@prakashsurya @lundman
libspl/mnttab: follow symlinks when resolving path via statx (openzfs…
6b232ca 
…#18469)

When the path argument to "zfs list -Ho name <path>" (or any caller of
zfs_path_to_zhandle()) is a symlink that crosses a mount boundary, the
wrong dataset is returned. Instead of returning the dataset that owns
the symlink's target, getextmntent() matches the dataset containing the
symlink itself.

For example, given two ZFS datasets "tank/ds1" and "tank/ds2", and a
symlink "/tank/ds1/link" pointing into "/tank/ds2":

    $ sudo zfs list -Ho name /tank/ds1/link
    tank/ds1

The expected (and previous) behavior is to return "tank/ds2", since the
symlink's target resides in that dataset.

The problem is in getextmntent(), in lib/libspl/os/linux/mnttab.c. That
function calls statx() on the caller-supplied path to obtain its mnt_id
(used to match against the mnt_id of each entry in /proc/self/mounts),
and it passes AT_SYMLINK_NOFOLLOW to that statx() call. As a result,
the mnt_id returned reflects the symlink's location rather than the
symlink target's mount, and the wrong /proc/self/mounts entry is
matched.

The same function also calls stat64() on the caller-supplied path
(used as a fallback when STATX_MNT_ID is not available, and to populate
the statbuf out-parameter). stat64() always follows symlinks, so the
statx() and stat64() calls were inconsistent: one resolved the symlink,
the other didn't. The AT_SYMLINK_NOFOLLOW behavior may be appropriate
when statx() is called on a mount entry from /proc/self/mounts (which
is always a real directory), but it is wrong for caller-supplied paths,
which may be symlinks.

This bug was introduced by 523d9d6 ("Validate mountpoint on
path-based unmount using statx"), which added the STATX_MNT_ID code
path. However, the bug was latent: config/user-statx.m4 omitted
"#define _GNU_SOURCE" when checking for STATX_MNT_ID in <sys/stat.h>,
so HAVE_STATX_MNT_ID was never defined, and the buggy statx() path was
never compiled in. getextmntent() always fell back to the dev_t
comparison via stat64(), which correctly follows symlinks.

The fix to that autoconf check, in 2b930f6 ("config: fix
STATX_MNT_ID detection"), caused HAVE_STATX_MNT_ID to be properly
defined on kernels that support it, activating the broken
AT_SYMLINK_NOFOLLOW path for the first time and exposing the
regression.

The fix is to drop AT_SYMLINK_NOFOLLOW from the statx() call so that
symlinks are followed, matching the behavior of stat64() on the same
path.

Verified with a minimal reproducer: created two ZFS datasets, placed a
symlink inside the first pointing into the second, and confirmed that
"zfs list -Ho name <symlink>" returns the dataset containing the
symlink's target rather than the dataset containing the symlink.

Signed-off-by: Prakash Surya <prakash.surya@perforce.com>
Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Reviewed-by: Mark Maybee <mark.maybee@delphix.com>
Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

Copilot code review Copilot
Copilot review effort
Applies to this pull request for everyone.Learn more about Copilot code review.
Copilot left review comments
@amotin amotin amotin approved these changes
@mmaybee mmaybee mmaybee approved these changes
@robn robn Awaiting requested review from robn
@behlendorf behlendorf Awaiting requested review from behlendorf
+1 more reviewer
@ixhamza ixhamza ixhamza approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

Status: Accepted Ready to integrate (reviewed, tested)

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

7 participants

@prakashsurya @satmandu @tonyhutter @amotin @mmaybee @ixhamza