Re: [LTP] syscalls: add v7.3 syscall numbers

[Andrea Cervesato via ltp <ltp@lists.linux.it>]

> > /* Roots of kernel internal pseudo filesystems, usable as fd sentinels */
> > #ifndef FD_PIDFS_ROOT
> > # define FD_PIDFS_ROOT		-10002
> 
> Could these new public macros use kernel-doc comments? Public macros added
> under include/lapi must be documented in syntax recognized by linuxdoc.

Not needed.

> 
> --- [PATCH 4/16] ---
> 
> > fchroot01: test fchroot() with a directory fd
> 
> Could the subject carry the "[STAGING]" prefix? Linux 7.2 is the latest
> stable release, while this test targets fchroot() from the 7.3 development
> cycle and is placed in runtest/staging.

This is correct for all the patches.

> > #define UPWARDS "../../../../../../../../../.."
> 
> Could this walk continue until the inode stops changing instead? LTP accepts
> any absolute TMPDIR, so a path more than ten components deep leaves this
> lookup at an intermediate directory and fails the root inode comparison on a
> correct kernel.

Hard to happen but correct.

> > 		SAFE_STAT(".", &st);
> > 		TST_EXP_EXPR(st.st_dev == realcwd.st_dev &&
> > 			st.st_ino == realcwd.st_ino,
> 
> Should this compare "." with realroot instead? mntns_install() resolves the
> target namespace's "/" and assigns it to both fs->root and fs->pwd; it does
> not restore the previous working directory. Unless the test starts in "/",
> this comparison fails on a correct kernel.

I need to verify.

> > static void setup(void)
> > {
> > 	ltpuser = SAFE_GETPWNAM("nobody");
> > }
> 
> Could setup query PR_GET_NO_NEW_PRIVS and return TCONF when it is already
> set? The bit is inherited and cannot be cleared, so such a launcher makes
> this test exercise the allowed-entry path and report a kernel failure.

Need to verify.

> 
> --- [PATCH 14/16] ---
> 
> > fchroot11: test failfs entry with no_new_privs
> 
> Could the subject carry the "[STAGING]" prefix? Linux 7.2 is the latest
> stable release, while this test targets fchroot() and failfs from the 7.3
> development cycle and is placed in runtest/staging.
> 
> > 	TST_EXP_FAIL(unshare(CLONE_NEWUSER), EPERM,
> > 		"user namespace creation blocked by the failfs root");
> 
> Could a separate unprivileged child first prove that user-namespace creation
> works, with TCONF when the environment blocks it? Runtime policy, seccomp, or
> an LSM can return EPERM even with CONFIG_USER_NS=y, making this assertion pass
> without testing the failfs restriction.

Will try.

Will send a v2.

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp