ZTS: check project ID inheritance and renames within a project directory
Covers both of the preceding changes. For the inheritance: a new symlink
and a new FIFO each add an object to the containing directory's project,
which only happens once non-regular files inherit a project ID, and a
symlink can then be renamed into a different directory carrying the same
project ID, which rename(2) permits only when the two project IDs match.
For the rename exemption: a regular file and a symlink are created
before the directory is tagged, so they carry no project ID of their
own, as every symlink on an existing pool does. Renaming each of them
within that directory afterwards fails with EXDEV unless the
cross-project check exempts renames whose source and target directories
are the same. The same renames are then repeated for objects created
after the tagging, along with replacing a symlink with "ln -sfn", and
again in an inheriting subdirectory.
A rename that does cross into a different project is still refused.
[7 lines not shown]
Allow renames within a single directory under project inheritance
A rename that keeps the object in the directory it already lives in
cannot move it between projects, so refusing it with EXDEV is never
right. Objects created before the previous commit carry no project ID of
their own, which makes this reachable on existing pools: a symlink in a
project directory cannot be renamed even to another name beside itself,
and "ln -sfn" over an existing path fails.
zfs_link() keeps its unconditional check. It has no source directory to
compare against -- a hard link names an object that may live anywhere --
so there is no equivalent "the object is already here" case to exempt.
Linking a pre-existing symlink, device node or FIFO into the project
directory that already holds it therefore still fails with EXDEV, until
the object is given a project ID of its own.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Matt Turner <mattst88 at gmail.com>
Closes #18932
Inherit the project ID for every object type
zfs_mknode() only assigned a project ID to regular files and
directories, so a symlink, device node, FIFO or socket created inside a
directory with ZFS_PROJINHERIT set was left at ZFS_DEFAULT_PROJID. The
cross-project checks in zfs_rename() and zfs_link() compare the object's
project ID against the directory's, so such an object is treated as
foreign to the very directory holding it, and cannot be renamed or
linked there at all -- "ln -sfn", which creates the new symlink under a
temporary name and renames it into place, fails with EXDEV.
ext4 and XFS store a project ID on every inode type and so do not have
this problem. Do the same, and quota-check new symlinks and rename
whiteouts against the inherited ID rather than the default one, so their
space is accounted to the project that owns them.
This changes accounting for newly created objects: symlinks, device
nodes and FIFOs now consume the project's quota where they previously
consumed none, so on a dataset already at its project quota, creating
[12 lines not shown]
[zfs-2.3.9] Add workaround for device_access ZTS test
Add workaround to get the device_access ZTS tests working on 2.3.9.
Signed-off-by: Tony Hutter <hutter2 at llnl.gov>
[zfs-2.2.11] Add workaround for device_access ZTS test
Add workaround to get the device_access ZTS tests working on 2.2.11.
Signed-off-by: Tony Hutter <hutter2 at llnl.gov>
dmu_redact_snap: Do proper cleanup on ENAMETOOLONG
If the redaction bookmark name exceeds ZFS_MAX_DATASET_NAME_LEN, we
leak the dataset hold, long hold, and decrypt key mapping on the target
snapshot, plus the same three references on each origin snapshot in
args[].
The leaked long holds leave those datasets busy such that destroy,
unmount, and zfs send will return EBUSY and the key mappings never drop.
Using goto out like the other error paths avoids this.
Reported-by: Grok 4.6 Build Beta
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Richard Yao <richard at ryao.dev>
Closes #18962
dmu_recv_begin_check: dsl_dataset_rele() should be called on ds
We call dsl_dataset_hold() to initialize ds, and are supposed to call
dsl_dataset_rele() on ds when we are done. In two error paths, we call
dsl_dataset_rele_flags(). If ds is an encrypted dataset, this can drop
the key mapping for the dataset, which will cause run time issues. On
unencrypted datasets, this is a no-op.
Reported-by: Grok 4.6 Build Beta
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Richard Yao <richard at ryao.dev>
Closes #18961
Linux: allow more time for snapshot automount teardown
Snapshot destruction can race with the delayed dput()/mntput() work
triggered after accessing a snapshot through .zfs/snapshot. If that
work takes longer than 20 milliseconds, the snapshot remains long-held
and zfs destroy returns EBUSY, which for example causes ZTS tests to
fail spuriously.
Relax the unmount deadline from 20 to max 40 milliseconds. The wait
continues to exit earlier than that if the teardown completes earlier.
This fixes spurious ZTS failures such as snapshot/snapshot_00
{1,2,3,5,6,7,8,12}_pos and snapshot/rollback_002_pos especially with
--enable-debug builds since e8e3076927039bc6a2094c43e3ac4e255884177f
Reviewed-by: George Melikov <mail at gmelikov.ru>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Rob Norris <rob.norris at klarasystems.com>
Signed-off-by: Wolfgang Hoschek <wolfgang.hoschek at mac.com>
Closes #18965
[zfs-2.2.11] Add 'capsh' to commands.cfg
Add missing 'capsh' to commands.cfg. It was included in
master with 7839c4b5e1 but that was not backported to this branch.
Signed-off-by: Tony Hutter <hutter2 at llnl.gov>
[zfs-2.3.9] Add 'capsh' to commands.cfg
Add missing 'capsh' to commands.cfg. It was included in
master with 7839c4b5e1 but that was not backported to this branch.
Signed-off-by: Tony Hutter <hutter2 at llnl.gov>
[zfs-2.4.4] Add 'capsh' to commands.cfg
Add missing 'capsh' to commands.cfg. It was included in
master with 7839c4b5e1 but that was not backported to this branch.
Signed-off-by: Tony Hutter <hutter2 at llnl.gov>
ZTS: device access tests
Tests that zpool create, add, attach and import all properly enforce the
restrictions on the calling user to access device nodes.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18960
vdev_disk: use calling cred to check for device access
bdev_file_open_by_path() does not do any kind of credential check on the
given device path, so we need to do our own. We temporarily swap in the
passed in credential as the task credential, then call kern_path() and
inode_permission(), which together will ensure the credential can both
see and access the given path.
For the reopening case, we use the kernel credential. The idea here is
that since the device was already open, we shouldn't fail to reopen just
because the calling user can't see it, which would prevent device
removal, offline, online, etc.
Include some light reorganising in the error paths, since we might not
always have a device handle to carry the current error.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
[2 lines not shown]
ZTS: test secpolicy_sys_config correctly limits namespace access
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18959
zfs_file_open: add cred arg, use it to check access
If we're opening a file on behalf of the user, we need to ensure that
that user actually has access to it. Add a credential parameter to
zfs_file_open() and use it when opening the file.
Existing callers use kcred for now to get the same behaviour as before.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18960
vdev_file: use calling cred to check for device access
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18960
secpolicy_zfs: add a note about the power of CAP_SYS_ADMIN
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18959
secpolicy_sys_config: only permit a global zone credential
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18959
secpolicy_nfs: remove, not used
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18959
vdev_open: pass credential to check for permission to open device
This commit adds a cred_t parameter to vdev_open() and threads it
through to all the vdev_op_open callbacks. The default is CRED(), ie the
credential of the calling task, which is usually some userspace control
process calling ioctl().
To handle the parallel vdev open case, we take additional and additional
reference to the cred for each task, and pass it down to vdev_open().
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18960
secpolicy_zinject: only permit a global zone credential
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18959
ZTS: test secpolicy_zinject correctly limits namespace access
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18959
config: detect idmap method via generic_permission test
Since the switch from implicit to explicit userns, and to idmap,
happened right across the kernel in major releases, so it is enough to
use a single test and apply the results everywhere.
generic_permission() is a nice simple function with a simple interface,
so useful for an unambiguous test.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18769
secpolicy_zinject: only permit a global zone credential
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18959
ZTS: test secpolicy_sys_config correctly limits namespace access
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18959
vdev_open: pass credential to check for permission to open device
This commit adds a cred_t parameter to vdev_open() and threads it
through to all the vdev_op_open callbacks. The default is CRED(), ie the
credential of the calling task, which is usually some userspace control
process calling ioctl().
To handle the parallel vdev open case, we take additional and additional
reference to the cred for each task, and pass it down to vdev_open().
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18960
vdev_file: use calling cred to check for device access
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18960
