tests/sys/audit/file-attribute-modify.c creates multiple files and directories, adds chflags SF_IMMUTABLE and UF_OFFLINE to the files, and relies on kyua to clean up the files/directories.
kyua does the best it can to clean up the directory, but it can't remove files with SF_IMMUTABLE on them.
The cleanup routine needs to un-SF_IMMUTABLE the file so kyua can clean up the file/directory.
Excerpt from :
I recently stumbled across undeletable files that are generated by kyua test runs,
-rwxr-xr-x 1 root wheel 0 May 9 13:10 /tmp/kyua.aB4q62/8676/work/fileforaudit
I haven't yet identified the test that generate those files, but it is impossible
to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but
on every boot the system argues that these file aren't deletable.
I tried to 'rm -rf' them by hand but, even this wasn't possible. I have looked for
any extend attributes, but I didn't find any.
Has anyone an idea how this is possible and may how these files can be deleted?
Excerpt from :
The issue is tests/sys/audit/file-attribute-modify.c , based on the file present that can’t be deleted. Can you please provide more information about the test run in a PR (I see how it can leave files behind, but I want to make sure it is what I think it is, first)?
Related upstream issue: https://github.com/jmmv/kyua/issues/142 .
Confirmed that `:chflagsat_success` is the cause.
A commit references this bug:
Date: Sun Jul 12 17:16:57 UTC 2020
New revision: 363132
Don't leave `path` behind when executing `:chflags_success`
Prior to this change a `SF_IMMUTABLE` chflagsat(2)'ed file (`path`) was left
behind, which sabotaged kyua(1) from being able to clean up the work directory,
This resulted in unnecessary work for folks having to clean up the work
directory on non-disposable systems, which defaults to `/tmp`. Use `UF_OFFLINE`
instead of `SF_IMMUTABLE`, in part because setting `SF_IMMUTABLE` isn't relevant
to the test and `SF_IMMUTABLE` cannot be cleared at all securelevels, as pointed
out by @asomers.
Additional work is required to catch cases like this upfront in the future to
avoid tester headache. See PR # 247765 for more details/followup.
Suggested by: asomers
Reviewed By: asomers, #tests
MFC after: 1 week
Sponsored by: DellEMC
Differential Revision: https://reviews.freebsd.org/D25561