Re: [LTP] syscalls: add v7.3 syscall numbers
Andrea Cervesato via ltp <[email protected]>
| Newsgroups | it.linux.lists.ltp |
|---|---|
| Message-ID | <[email protected]> |
> > /* 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
[email protected]
--
Mailing list info: https://lists.linux.it/listinfo/ltp