Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"chflags uunlink foo" on FreeBSD fails with EOPNOSUPP ("chflags sunlink foo" works) #16809

Open
ngie-eign opened this issue Nov 26, 2024 · 1 comment · May be fixed by #16820
Open

"chflags uunlink foo" on FreeBSD fails with EOPNOSUPP ("chflags sunlink foo" works) #16809

ngie-eign opened this issue Nov 26, 2024 · 1 comment · May be fixed by #16820

Comments

@ngie-eign
Copy link

chflags sunlink foo works, but chflags uunlink foo does not.

Example:

% chflags uunlink foo 
chflags: foo: Operation not supported
% chflags sunlink foo
chflags: foo: Operation not permitted
% sudo chflags sunlink foo
% uname -a
FreeBSD gilot.local 14.1-RELEASE-p4 FreeBSD 14.1-RELEASE-p4 GENERIC amd64

This is probably because zfs_freebsd_setattr(..) does not map UF_UNLINK to a valid fflags attribute:

if ((fflags & ~(SF_IMMUTABLE|SF_APPEND|SF_NOUNLINK|UF_ARCHIVE|
UF_NODUMP|UF_SYSTEM|UF_HIDDEN|UF_READONLY|UF_REPARSE|
UF_OFFLINE|UF_SPARSE)) != 0)
return (EOPNOTSUPP);

Discovered when running a kyua unittest on /tmp backed by ZFS.

Reported on FreeBSD bugzilla as well.

ngie-eign added a commit to ngie-eign/kyua that referenced this issue Nov 29, 2024
The testcases prior to this change relied on setting UF_UNLINK, which
is unfortunately bugged on ZFS: ZFS does not treat UF_UNLINK as a valid
value for fflags, which causes the testcases to fail.

Switch to SF_UNLINK. This particular fflag requires root privileges, so
add the needed metadata to the Kyuafile.

As part of this, I needed to convert the test from atf-c++(3) to
atf-c(3). The atf-c++(3) APIs do not have the printf-like equivalent
formatting, so it was very difficult figuring out why things weren't
working in atf-c++(3).

While here, clean up the code to DRY some of the repeated logic that it
contained.

The UF_UNLINK bug has been reported in openzfs/zfs#16809 .
@ngie-eign
Copy link
Author

ngie-eign commented Nov 29, 2024

Ah neat. Easy fix incoming...

fbsd-current# mdconfig -a -t malloc -s 100m
md0
fbsd-current# mdconfig -a -t malloc -s 100m
md1
fbsd-current# zpool create howitzer md0 md1
fbsd-current# cd /howitzer
fbsd-current# : > foo
fbsd-current# chflags uunlink foo
fbsd-current# ls -l
total 1
-rw-r--r--  1 root wheel 0 Nov 29 10:44 foo
fbsd-current# rm foo
rm: foo: Operation not permitted
fbsd-current# chflags nouunlink foo
fbsd-current# rm foo
fbsd-current# 

ngie-eign added a commit to ngie-eign/openzfs-zfs that referenced this issue Nov 29, 2024
The `UF_NOUNLINK` chflags fflag is analogous to `SF_NOUNLINK`, but instead
of requiring superuser privileges when setting `SF_NOUNLINK`, unprivileged
users (in addition to root) can set `UF_NOUNLINK` on compatible paths.

This makes commands like `chflags uunlink <foo>` work on FreeBSD.

This closes openzfs#16809.

Signed-off-by: Enji Cooper <[email protected]>
@ngie-eign ngie-eign linked a pull request Nov 29, 2024 that will close this issue
13 tasks
ngie-eign added a commit to ngie-eign/openzfs-zfs that referenced this issue Nov 29, 2024
The `UF_NOUNLINK` chflags fflag is analogous to `SF_NOUNLINK`, but
instead of requiring superuser privileges when setting `SF_NOUNLINK`,
unprivileged users (in addition to root) can set `UF_NOUNLINK` on
compatible paths.

This makes commands like `chflags uunlink <foo>` work on FreeBSD.

This closes openzfs#16809.

Signed-off-by: Enji Cooper <[email protected]>
ngie-eign added a commit to ngie-eign/kyua that referenced this issue Nov 30, 2024
The testcases prior to this change relied on setting UF_NOUNLINK, which
is unfortunately bugged on ZFS: ZFS does not treat UF_NOUNLINK as a valid
value for fflags, which causes the testcases to fail.

Switch to SF_NOUNLINK. This particular fflag works work ZFS, unlike
UF_NOUNLINK, but requires root privileges, so add the needed metadata
to the Kyuafile.

As part of this, I needed to convert the test from atf-c++(3) to
atf-c(3). The atf-c++(3) APIs do not have the printf-like equivalent
formatting, so it was very difficult figuring out why things weren't
working in atf-c++(3).

While here, clean up the code to DRY some of the repeated logic that it
contained.

The UF_NOUNLINK bug has been reported in openzfs/zfs#16809 .
ngie-eign added a commit to ngie-eign/kyua that referenced this issue Dec 1, 2024
The testcases prior to this change relied on setting UF_NOUNLINK, which
is unfortunately bugged on ZFS: ZFS does not treat UF_NOUNLINK as a valid
value for fflags, which causes the testcases to fail.

Switch to SF_NOUNLINK. This particular fflag works work ZFS, unlike
UF_NOUNLINK, but requires root privileges, so add the needed metadata
to the Kyuafile.

As part of this, I needed to convert the test from atf-c++(3) to
atf-c(3). The atf-c++(3) APIs do not have the printf-like equivalent
formatting, so it was very difficult figuring out why things weren't
working in atf-c++(3).

While here, clean up the code to DRY some of the repeated logic that it
contained.

The UF_NOUNLINK bug has been reported in openzfs/zfs#16809 .

Fixes:  e26c804
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant