| Message ID | 20220628222941.2642917-1-jeffxu@google.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | selftests/landlock: skip ptrace_test when YAMA is enabled | expand |
Hi Jeff, Thanks for this patch. Here are some comments: On 29/06/2022 00:29, Jeff Xu wrote: > ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled. > > Cc: Jorge Lucangeli Obes <jorgelo@chromium.org> > Cc: Guenter Roeck <groeck@chromium.org> > Cc: Kees Cook <keescook@chromium.org> > Cc: Mickaël Salaün <mic@digikod.net> > Tested-by: Jeff Xu <jeffxu@google.com> > Signed-off-by: Jeff Xu <jeffxu@google.com> > Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f > --- > .../testing/selftests/landlock/ptrace_test.c | 49 +++++++++++++++++++ > 1 file changed, 49 insertions(+) > > diff --git a/tools/testing/selftests/landlock/ptrace_test.c b/tools/testing/selftests/landlock/ptrace_test.c > index c28ef98ff3ac..ef2d36f56764 100644 > --- a/tools/testing/selftests/landlock/ptrace_test.c > +++ b/tools/testing/selftests/landlock/ptrace_test.c > @@ -226,6 +226,44 @@ FIXTURE_TEARDOWN(hierarchy) > { > } > Please move these new helpers after test_ptrace_read() and make them static. > +int open_sysfs(const char *path, int flags, int *fd) > +{ > + *fd = open(path, flags); > + > + if (fd < 0) > + return -1; > + > + return 0; > +} open_sysfs() can be replaced with a call to open(). This makes the code simpler. > + > +int read_sysfs_int_fd(int fd, int *val) > +{ > + char buf[2]; > + > + if (read(fd, buf, sizeof(buf)) < 0) I guess `read(fd, buf, 1)` should be enough and it enables keeping the final '\0'. A comment should state that this helper only read the first digit (which is enough for Yama). > + return -1; > + > + buf[sizeof(buf) - 1] = '\0'; Use `char buf[2] = {};` instead. > + *val = atoi(buf); > + return 0; > +} Same for read_sysfs_int_fd(), you can inline the code in read_sysfs_int(). > + > +int read_sysfs_int(const char *path, int *val) > +{ > + int fd; > + > + if (open_sysfs(path, O_RDONLY, &fd) != 0) > + return -1; > + > + if (read_sysfs_int_fd(fd, val) != 0) { > + close(fd); > + return -1; > + } > + > + close(fd); > + return 0; > +} > + > /* Test PTRACE_TRACEME and PTRACE_ATTACH for parent and child. */ > TEST_F(hierarchy, trace) > { > @@ -235,6 +273,17 @@ TEST_F(hierarchy, trace) > char buf_parent; > long ret; > > + int ptrace_val; > + > + ASSERT_EQ(0, read_sysfs_int("/proc/sys/kernel/yama/ptrace_scope", > + &ptrace_val)); This is a good test but it fail if Yama is not built in the kernel. For now, I think you can create two helpers named something like is_yama_restricting() and is_yama_denying() (for admin-only attach). > + if (ptrace_val != 0) { Some tests should work even if ptrace_val == 1. SKIP() should only be called when the test would fail. Can you please check all tests with all Yama values? > + /* > + * Yama's scoped ptrace is presumed disabled. If enabled, skip. > + */ > + SKIP(return, "yama is enabled, skip current test"); > + } > + > /* > * Removes all effective and permitted capabilities to not interfere > * with cap_ptrace_access_check() in case of PTRACE_MODE_FSCREDS.
On 29/06/2022 00:29, Jeff Xu wrote: > ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled. > > Cc: Jorge Lucangeli Obes <jorgelo@chromium.org> > Cc: Guenter Roeck <groeck@chromium.org> > Cc: Kees Cook <keescook@chromium.org> > Cc: Mickaël Salaün <mic@digikod.net> > Tested-by: Jeff Xu <jeffxu@google.com> I guess we assume that Signed-off-by implies Tested-by, so you can remove this Tested-by. > Signed-off-by: Jeff Xu <jeffxu@google.com> > Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f Please remove this Change-Id too.
Hi Mickaël Thank you for your review, please see my response below. > Hi Jeff, > > Thanks for this patch. Here are some comments: > > On 29/06/2022 00:29, Jeff Xu wrote: > > ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled. > > > > Cc: Jorge Lucangeli Obes <jorgelo@chromium.org> > > Cc: Guenter Roeck <groeck@chromium.org> > > Cc: Kees Cook <keescook@chromium.org> > > Cc: Mickaël Salaün <mic@digikod.net> > > Tested-by: Jeff Xu <jeffxu@google.com> > > Signed-off-by: Jeff Xu <jeffxu@google.com> > > Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f > > --- > > .../testing/selftests/landlock/ptrace_test.c | 49 +++++++++++++++++++ > > 1 file changed, 49 insertions(+) > > > > diff --git a/tools/testing/selftests/landlock/ptrace_test.c b/tools/testing/selftests/landlock/ptrace_test.c > > index c28ef98ff3ac..ef2d36f56764 100644 > > --- a/tools/testing/selftests/landlock/ptrace_test.c > > +++ b/tools/testing/selftests/landlock/ptrace_test.c > > @@ -226,6 +226,44 @@ FIXTURE_TEARDOWN(hierarchy) > > { > > } > > > > Please move these new helpers after test_ptrace_read() and make them static. > > > +int open_sysfs(const char *path, int flags, int *fd) > > +{ > > + *fd = open(path, flags); > > + > > + if (fd < 0) > > + return -1; > > + > > + return 0; > > +} > > open_sysfs() can be replaced with a call to open(). This makes the code > simpler. > > > + > > +int read_sysfs_int_fd(int fd, int *val) > > +{ > > + char buf[2]; > > + > > + if (read(fd, buf, sizeof(buf)) < 0) > > I guess `read(fd, buf, 1)` should be enough and it enables keeping the > final '\0'. A comment should state that this helper only read the first > digit (which is enough for Yama). > > > + return -1; > > + > > + buf[sizeof(buf) - 1] = '\0'; > > Use `char buf[2] = {};` instead. > > > + *val = atoi(buf); > > + return 0; > > +} > Thanks, I will revise the code, my original thought is to extend it as a common utility function to parse an int, let me finish it in the next iteration of patch. > Same for read_sysfs_int_fd(), you can inline the code in read_sysfs_int(). > This is a good test but it fail if Yama is not built in the kernel. > I don't have a kernel built without yama, so my original thought is to fail it and whoever has the need can fix it. What is your thought on this ? > For now, I think you can create two helpers named something like > is_yama_restricting() and is_yama_denying() (for admin-only attach). > Can you please clarify on the difference/implementation on those 2 ? > > + if (ptrace_val != 0) { > > Some tests should work even if ptrace_val == 1. SKIP() should only be > called when the test would fail. Can you please check all tests with all > Yama values? Sure, below are yama cases with testing result: ===================================== case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other process running under the same uid, as long as it is dumpable (i.e. did not transition uids, start privileged, or have called prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is unchanged. Test: All passing ====================================== Case 1 - restricted ptrace: a process must have a predefined relationship with the inferior it wants to call PTRACE_ATTACH on. By default, this relationship is that of only its descendants when the above classic criteria is also met. To change the relationship, an inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare an allowed debugger PID to call PTRACE_ATTACH on the inferior. Using PTRACE_TRACEME is unchanged. Test: // Base_test: 7/7 pass. // Fs_test 46/48 pass //. not ok 47 layout2_overlay.no_restriction //. not ok 48 layout2_overlay.same_content_different_file // Ptrace_test 4/8 pass // # FAIL hierarchy.allow_without_domain.trace // # FAIL hierarchy.deny_with_parent_domain.trace // # FAIL hierarchy.allow_sibling_domain.trace // # FAIL hierarchy.deny_with_nested_and_parent_domain.trace ==================================================== Case 2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace with PTRACE_ATTACH, or through children calling PTRACE_TRACEME. Case 3 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via PTRACE_TRACEME. Once set, this sysctl value cannot be changed. Test: *case2 and case3 have the same results: // Base_test: 7/7 pass. // Fs_test 46/48 pass //. not ok 47 layout2_overlay.no_restriction //. not ok 48 layout2_overlay.same_content_different_file // Ptrace 2/8 pass //. ok 4 hierarchy.deny_with_sibling_domain.trace //. ok 8 hierarchy.deny_with_forked_domain.trace // the other 6 tests failed with timeout. =============================================== Do you know why fs_test (47,48) is failing when yama value = 1,2,3 ? FOR SKIP, it might be messy to add SKIP after checking variant names in TEST_F(), (too many if/else , which make it less readable), ideally this should be when or before FIXTURE_VARIANT_ADD() is called. or somehow refactor the code to remove the variant check in TEST_F() Is there a better way ? Thanks Best Regards, Jeff On Thu, Jun 30, 2022 at 8:31 AM Mickaël Salaün <mic@digikod.net> wrote: > > > On 29/06/2022 00:29, Jeff Xu wrote: > > ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled. > > > > Cc: Jorge Lucangeli Obes <jorgelo@chromium.org> > > Cc: Guenter Roeck <groeck@chromium.org> > > Cc: Kees Cook <keescook@chromium.org> > > Cc: Mickaël Salaün <mic@digikod.net> > > Tested-by: Jeff Xu <jeffxu@google.com> > > I guess we assume that Signed-off-by implies Tested-by, so you can > remove this Tested-by. > > > Signed-off-by: Jeff Xu <jeffxu@google.com> > > Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f > > Please remove this Change-Id too.
A correction (resend with plain text) > ===================================== > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other > process running under the same uid, as long as it is dumpable (i.e. > did not transition uids, start privileged, or have called > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > unchanged. // Base_test: 7/7 pass. // Fs_test 46/48 pass //. not ok 47 layout2_overlay.no_restriction //. not ok 48 layout2_overlay.same_content_different_file // Ptrace 8/8 pass Note: 47,48 of fs_test are failing for all YAMA config values (0-3) On Tue, Jul 5, 2022 at 2:49 PM Jeff Xu <jeffxu@google.com> wrote: > > Hi Mickaël > > Thank you for your review, please see my response below. > > > Hi Jeff, > > > > Thanks for this patch. Here are some comments: > > > > On 29/06/2022 00:29, Jeff Xu wrote: > > > ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled. > > > > > > Cc: Jorge Lucangeli Obes <jorgelo@chromium.org> > > > Cc: Guenter Roeck <groeck@chromium.org> > > > Cc: Kees Cook <keescook@chromium.org> > > > Cc: Mickaël Salaün <mic@digikod.net> > > > Tested-by: Jeff Xu <jeffxu@google.com> > > > Signed-off-by: Jeff Xu <jeffxu@google.com> > > > Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f > > > --- > > > .../testing/selftests/landlock/ptrace_test.c | 49 +++++++++++++++++++ > > > 1 file changed, 49 insertions(+) > > > > > > diff --git a/tools/testing/selftests/landlock/ptrace_test.c b/tools/testing/selftests/landlock/ptrace_test.c > > > index c28ef98ff3ac..ef2d36f56764 100644 > > > --- a/tools/testing/selftests/landlock/ptrace_test.c > > > +++ b/tools/testing/selftests/landlock/ptrace_test.c > > > @@ -226,6 +226,44 @@ FIXTURE_TEARDOWN(hierarchy) > > > { > > > } > > > > > > > Please move these new helpers after test_ptrace_read() and make them static. > > > > > +int open_sysfs(const char *path, int flags, int *fd) > > > +{ > > > + *fd = open(path, flags); > > > + > > > + if (fd < 0) > > > + return -1; > > > + > > > + return 0; > > > +} > > > > open_sysfs() can be replaced with a call to open(). This makes the code > > simpler. > > > > > + > > > +int read_sysfs_int_fd(int fd, int *val) > > > +{ > > > + char buf[2]; > > > + > > > + if (read(fd, buf, sizeof(buf)) < 0) > > > > I guess `read(fd, buf, 1)` should be enough and it enables keeping the > > final '\0'. A comment should state that this helper only read the first > > digit (which is enough for Yama). > > > > > + return -1; > > > + > > > + buf[sizeof(buf) - 1] = '\0'; > > > > Use `char buf[2] = {};` instead. > > > > > + *val = atoi(buf); > > > + return 0; > > > +} > > > > Thanks, I will revise the code, my original thought is to extend it as > a common utility function to parse an int, let me finish it in the > next iteration of patch. > > > Same for read_sysfs_int_fd(), you can inline the code in read_sysfs_int(). > > This is a good test but it fail if Yama is not built in the kernel. > > > I don't have a kernel built without yama, so my original thought is to > fail it and whoever has the need can fix it. What is your thought on this ? > > > For now, I think you can create two helpers named something like > > is_yama_restricting() and is_yama_denying() (for admin-only attach). > > > Can you please clarify on the difference/implementation on those 2 ? > > > > + if (ptrace_val != 0) { > > > > Some tests should work even if ptrace_val == 1. SKIP() should only be > > called when the test would fail. Can you please check all tests with all > > Yama values? > Sure, below are yama cases with testing result: > ===================================== > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other > process running under the same uid, as long as it is dumpable (i.e. > did not transition uids, start privileged, or have called > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > unchanged. > > Test: All passing > ====================================== > Case 1 - restricted ptrace: a process must have a predefined relationship > with the inferior it wants to call PTRACE_ATTACH on. By default, > this relationship is that of only its descendants when the above > classic criteria is also met. To change the relationship, an > inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare > an allowed debugger PID to call PTRACE_ATTACH on the inferior. > Using PTRACE_TRACEME is unchanged. > > Test: > // Base_test: 7/7 pass. > // Fs_test 46/48 pass > //. not ok 47 layout2_overlay.no_restriction > //. not ok 48 layout2_overlay.same_content_different_file > // Ptrace_test 4/8 pass > // # FAIL hierarchy.allow_without_domain.trace > // # FAIL hierarchy.deny_with_parent_domain.trace > // # FAIL hierarchy.allow_sibling_domain.trace > // # FAIL hierarchy.deny_with_nested_and_parent_domain.trace > ==================================================== > Case 2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace > with PTRACE_ATTACH, or through children calling PTRACE_TRACEME. > Case 3 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via > PTRACE_TRACEME. Once set, this sysctl value cannot be changed. > Test: *case2 and case3 have the same results: > // Base_test: 7/7 pass. > // Fs_test 46/48 pass > //. not ok 47 layout2_overlay.no_restriction > //. not ok 48 layout2_overlay.same_content_different_file > // Ptrace 2/8 pass > //. ok 4 hierarchy.deny_with_sibling_domain.trace > //. ok 8 hierarchy.deny_with_forked_domain.trace > // the other 6 tests failed with timeout. > =============================================== > > Do you know why fs_test (47,48) is failing when yama value = 1,2,3 ? > > FOR SKIP, it might be messy to add SKIP after checking variant names > in TEST_F(), (too many if/else , which make it less readable), > ideally this should be when or before FIXTURE_VARIANT_ADD() is called. > or somehow refactor the code to remove the variant check in TEST_F() > > Is there a better way ? > > Thanks > Best Regards, > Jeff > > > > On Thu, Jun 30, 2022 at 8:31 AM Mickaël Salaün <mic@digikod.net> wrote: > > > > > > On 29/06/2022 00:29, Jeff Xu wrote: > > > ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled. > > > > > > Cc: Jorge Lucangeli Obes <jorgelo@chromium.org> > > > Cc: Guenter Roeck <groeck@chromium.org> > > > Cc: Kees Cook <keescook@chromium.org> > > > Cc: Mickaël Salaün <mic@digikod.net> > > > Tested-by: Jeff Xu <jeffxu@google.com> > > > > I guess we assume that Signed-off-by implies Tested-by, so you can > > remove this Tested-by. > > > > > Signed-off-by: Jeff Xu <jeffxu@google.com> > > > Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f > > > > Please remove this Change-Id too.
On 05/07/2022 23:49, Jeff Xu wrote: > Hi Mickaël > > Thank you for your review, please see my response below. > >> Hi Jeff, >> >> Thanks for this patch. Here are some comments: >> >> On 29/06/2022 00:29, Jeff Xu wrote: >>> ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled. >>> >>> Cc: Jorge Lucangeli Obes <jorgelo@chromium.org> >>> Cc: Guenter Roeck <groeck@chromium.org> >>> Cc: Kees Cook <keescook@chromium.org> >>> Cc: Mickaël Salaün <mic@digikod.net> >>> Tested-by: Jeff Xu <jeffxu@google.com> >>> Signed-off-by: Jeff Xu <jeffxu@google.com> >>> Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f >>> --- >>> .../testing/selftests/landlock/ptrace_test.c | 49 +++++++++++++++++++ >>> 1 file changed, 49 insertions(+) >>> >>> diff --git a/tools/testing/selftests/landlock/ptrace_test.c b/tools/testing/selftests/landlock/ptrace_test.c >>> index c28ef98ff3ac..ef2d36f56764 100644 >>> --- a/tools/testing/selftests/landlock/ptrace_test.c >>> +++ b/tools/testing/selftests/landlock/ptrace_test.c >>> @@ -226,6 +226,44 @@ FIXTURE_TEARDOWN(hierarchy) >>> { >>> } >>> >> >> Please move these new helpers after test_ptrace_read() and make them static. >> >>> +int open_sysfs(const char *path, int flags, int *fd) >>> +{ >>> + *fd = open(path, flags); >>> + >>> + if (fd < 0) >>> + return -1; >>> + >>> + return 0; >>> +} >> >> open_sysfs() can be replaced with a call to open(). This makes the code >> simpler. >> >>> + >>> +int read_sysfs_int_fd(int fd, int *val) >>> +{ >>> + char buf[2]; >>> + >>> + if (read(fd, buf, sizeof(buf)) < 0) >> >> I guess `read(fd, buf, 1)` should be enough and it enables keeping the >> final '\0'. A comment should state that this helper only read the first >> digit (which is enough for Yama). >> >>> + return -1; >>> + >>> + buf[sizeof(buf) - 1] = '\0'; >> >> Use `char buf[2] = {};` instead. >> >>> + *val = atoi(buf); >>> + return 0; >>> +} >> > > Thanks, I will revise the code, my original thought is to extend it as > a common utility function to parse an int, let me finish it in the > next iteration of patch. > >> Same for read_sysfs_int_fd(), you can inline the code in read_sysfs_int(). >> This is a good test but it fail if Yama is not built in the kernel. >> > I don't have a kernel built without yama, so my original thought is to > fail it and whoever has the need can fix it. What is your thought on this ? The current status is that all tests should pass with a minimal kernel configuration (cf. the test config file). Yama is an exception for these tests, not the norm, so you also need to test against a kernel without Yama. > >> For now, I think you can create two helpers named something like >> is_yama_restricting() and is_yama_denying() (for admin-only attach). >> > Can you please clarify on the difference/implementation on those 2 ? They should check for the different values of ptrace_scope: https://docs.kernel.org/admin-guide/LSM/Yama.html - is_yama_restricting() should return true if ptrace_scope == 1 - is_yama_denying() should return true if ptrace_scope >= 2 Restricted ptrace only forbids a child process to ptrace its parents. There is no specific restriction for a parent to ptrace its children. Ptracing is always denied if ptrace_scope >= 2 (without specific capabilties, which is the case for these tests). > >>> + if (ptrace_val != 0) { >> >> Some tests should work even if ptrace_val == 1. SKIP() should only be >> called when the test would fail. Can you please check all tests with all >> Yama values? > Sure, below are yama cases with testing result: > ===================================== > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other > process running under the same uid, as long as it is dumpable (i.e. > did not transition uids, start privileged, or have called > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > unchanged. > > Test: All passing > ====================================== > Case 1 - restricted ptrace: a process must have a predefined relationship > with the inferior it wants to call PTRACE_ATTACH on. By default, > this relationship is that of only its descendants when the above > classic criteria is also met. To change the relationship, an > inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare > an allowed debugger PID to call PTRACE_ATTACH on the inferior. > Using PTRACE_TRACEME is unchanged. > > Test: > // Base_test: 7/7 pass. > // Fs_test 46/48 pass > //. not ok 47 layout2_overlay.no_restriction > //. not ok 48 layout2_overlay.same_content_different_file > // Ptrace_test 4/8 pass > // # FAIL hierarchy.allow_without_domain.trace > // # FAIL hierarchy.deny_with_parent_domain.trace > // # FAIL hierarchy.allow_sibling_domain.trace > // # FAIL hierarchy.deny_with_nested_and_parent_domain.trace > ==================================================== > Case 2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace > with PTRACE_ATTACH, or through children calling PTRACE_TRACEME. > Case 3 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via > PTRACE_TRACEME. Once set, this sysctl value cannot be changed. > Test: *case2 and case3 have the same results: > // Base_test: 7/7 pass. > // Fs_test 46/48 pass > //. not ok 47 layout2_overlay.no_restriction > //. not ok 48 layout2_overlay.same_content_different_file > // Ptrace 2/8 pass > //. ok 4 hierarchy.deny_with_sibling_domain.trace > //. ok 8 hierarchy.deny_with_forked_domain.trace > // the other 6 tests failed with timeout. > =============================================== > > Do you know why fs_test (47,48) is failing when yama value = 1,2,3 ? These are all the overlayfs tests but I don't know why they are failing with Yama. Could you please pinpoint the exact(s) failing ASSERT? (Whatever my following comments, this would be valuable to know the issue.) > > FOR SKIP, it might be messy to add SKIP after checking variant names > in TEST_F(), (too many if/else , which make it less readable), > ideally this should be when or before FIXTURE_VARIANT_ADD() is called. > or somehow refactor the code to remove the variant check in TEST_F() > > Is there a better way ? OK, let's follow another approach. The first alternative would be to disable Yama for all the Landlock ptrace tests. You'll first need to save the current Yama settings and restore it after each test, even if they failed. I think this alternative makes sense because Landlock tests should not be about Yama. The second alternative would be to test with and without Yama, with different Yama settings. That would also require to disable Yama for 1/3 or 1/4 of tests. The downside of this alternative is that it requires 3 or 4 times variants, and it actually test Yama, which is not the goal of the Landlock tests. Anyway, you also need to update the comment about Yama in the current tests.
On 07/07/2022 01:35, Jeff Xu wrote: > a correction: > > ===================================== > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > any other > process running under the same uid, as long as it is dumpable (i.e. > did not transition uids, start privileged, or have called > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > unchanged. > > Test: All passing > > // Base_test: 7/7 pass. > // Fs_test 46/48 pass > //. not ok 47 layout2_overlay.no_restriction > //. not ok 48 layout2_overlay.same_content_different_file > // Ptrace 8/8 pass Hmm, well, it is not related to Yama then. Could it be linked to other Chromium OS non-upstream patches?
> > a correction: > > > > ===================================== > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > any other > > process running under the same uid, as long as it is dumpable (i.e. > > did not transition uids, start privileged, or have called > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > unchanged. > > > > Test: All passing > > > > // Base_test: 7/7 pass. > > // Fs_test 46/48 pass > > //. not ok 47 layout2_overlay.no_restriction > > //. not ok 48 layout2_overlay.same_content_different_file > > // Ptrace 8/8 pass > Hmm, well, it is not related to Yama then. Could it be linked to other > Chromium OS non-upstream patches? fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not enabled in chromeOS. If there is a reliable way of detecting OVERLAYFS (checking mount overlayfs is successful ? ), this is a good candidate to add SKIP. Overall, all the failure of landlock selftest seen in chromeOS are expected, we just need to modify the test. Thanks Best Regards Jeff On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote: > > > On 07/07/2022 01:35, Jeff Xu wrote: > > a correction: > > > > ===================================== > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > any other > > process running under the same uid, as long as it is dumpable (i.e. > > did not transition uids, start privileged, or have called > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > unchanged. > > > > Test: All passing > > > > // Base_test: 7/7 pass. > > // Fs_test 46/48 pass > > //. not ok 47 layout2_overlay.no_restriction > > //. not ok 48 layout2_overlay.same_content_different_file > > // Ptrace 8/8 pass > > Hmm, well, it is not related to Yama then. Could it be linked to other > Chromium OS non-upstream patches?
On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote: > > > > a correction: > > > > > > ===================================== > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > any other > > > process running under the same uid, as long as it is dumpable (i.e. > > > did not transition uids, start privileged, or have called > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > unchanged. > > > > > > Test: All passing > > > > > > // Base_test: 7/7 pass. > > > // Fs_test 46/48 pass > > > //. not ok 47 layout2_overlay.no_restriction > > > //. not ok 48 layout2_overlay.same_content_different_file > > > // Ptrace 8/8 pass > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > Chromium OS non-upstream patches? > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > enabled in chromeOS. > If there is a reliable way of detecting OVERLAYFS (checking mount > overlayfs is successful ? ), this is a good candidate to add SKIP. > IS_ENABLED(CONFIG_OVERLAY_FS) ? > Overall, all the failure of landlock selftest seen in chromeOS are > expected, we just need to modify the test. > > Thanks > Best Regards > Jeff > > > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote: > > > > > > On 07/07/2022 01:35, Jeff Xu wrote: > > > a correction: > > > > > > ===================================== > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > any other > > > process running under the same uid, as long as it is dumpable (i.e. > > > did not transition uids, start privileged, or have called > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > unchanged. > > > > > > Test: All passing > > > > > > // Base_test: 7/7 pass. > > > // Fs_test 46/48 pass > > > //. not ok 47 layout2_overlay.no_restriction > > > //. not ok 48 layout2_overlay.same_content_different_file > > > // Ptrace 8/8 pass > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > Chromium OS non-upstream patches?
> > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > Chromium OS non-upstream patches? > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > enabled in chromeOS. > > If there is a reliable way of detecting OVERLAYFS (checking mount > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? Could be. Landlock selftest currently is a user space program though, IS_ENABLED will depend on the kernel header during compile time. On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote: > > On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote: > > > > > > a correction: > > > > > > > > ===================================== > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > any other > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > did not transition uids, start privileged, or have called > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > unchanged. > > > > > > > > Test: All passing > > > > > > > > // Base_test: 7/7 pass. > > > > // Fs_test 46/48 pass > > > > //. not ok 47 layout2_overlay.no_restriction > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > // Ptrace 8/8 pass > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > Chromium OS non-upstream patches? > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > enabled in chromeOS. > > If there is a reliable way of detecting OVERLAYFS (checking mount > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > Overall, all the failure of landlock selftest seen in chromeOS are > > expected, we just need to modify the test. > > > > Thanks > > Best Regards > > Jeff > > > > > > > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote: > > > > > > > > > On 07/07/2022 01:35, Jeff Xu wrote: > > > > a correction: > > > > > > > > ===================================== > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > any other > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > did not transition uids, start privileged, or have called > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > unchanged. > > > > > > > > Test: All passing > > > > > > > > // Base_test: 7/7 pass. > > > > // Fs_test 46/48 pass > > > > //. not ok 47 layout2_overlay.no_restriction > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > // Ptrace 8/8 pass > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > Chromium OS non-upstream patches?
On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > Chromium OS non-upstream patches? > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > enabled in chromeOS. > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > Could be. Landlock selftest currently is a user space program though, > IS_ENABLED will depend on the kernel header during compile time. > Ah, sorry, I thought it was an in-kernel test. Userspace should be able to determine if overlayfs is supported by checking /sys/fs/ or possibly /proc/fs/. Guenter > > On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote: > > > > On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > a correction: > > > > > > > > > > ===================================== > > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > > any other > > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > > did not transition uids, start privileged, or have called > > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > > unchanged. > > > > > > > > > > Test: All passing > > > > > > > > > > // Base_test: 7/7 pass. > > > > > // Fs_test 46/48 pass > > > > > //. not ok 47 layout2_overlay.no_restriction > > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > > // Ptrace 8/8 pass > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > Chromium OS non-upstream patches? > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > enabled in chromeOS. > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > Overall, all the failure of landlock selftest seen in chromeOS are > > > expected, we just need to modify the test. > > > > > > Thanks > > > Best Regards > > > Jeff > > > > > > > > > > > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote: > > > > > > > > > > > > On 07/07/2022 01:35, Jeff Xu wrote: > > > > > a correction: > > > > > > > > > > ===================================== > > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > > any other > > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > > did not transition uids, start privileged, or have called > > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > > unchanged. > > > > > > > > > > Test: All passing > > > > > > > > > > // Base_test: 7/7 pass. > > > > > // Fs_test 46/48 pass > > > > > //. not ok 47 layout2_overlay.no_restriction > > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > > // Ptrace 8/8 pass > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > Chromium OS non-upstream patches?
> On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > enabled in chromeOS. > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > Could be. Landlock selftest currently is a user space program though, > > IS_ENABLED will depend on the kernel header during compile time. > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > able to determine if overlayfs is supported by checking /sys/fs/ or > possibly /proc/fs/. Thanks for clarifying. lsmod might be the one, such as: lsmod | grep overlayfs Thanks Jeff On Thu, Jul 14, 2022 at 1:40 PM Guenter Roeck <groeck@google.com> wrote: > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > enabled in chromeOS. > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > Could be. Landlock selftest currently is a user space program though, > > IS_ENABLED will depend on the kernel header during compile time. > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > able to determine if overlayfs is supported by checking /sys/fs/ or > possibly /proc/fs/. > > Guenter > > > > > On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote: > > > > > > On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > a correction: > > > > > > > > > > > > ===================================== > > > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > > > any other > > > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > > > did not transition uids, start privileged, or have called > > > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > > > unchanged. > > > > > > > > > > > > Test: All passing > > > > > > > > > > > > // Base_test: 7/7 pass. > > > > > > // Fs_test 46/48 pass > > > > > > //. not ok 47 layout2_overlay.no_restriction > > > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > > > // Ptrace 8/8 pass > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > enabled in chromeOS. > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > Overall, all the failure of landlock selftest seen in chromeOS are > > > > expected, we just need to modify the test. > > > > > > > > Thanks > > > > Best Regards > > > > Jeff > > > > > > > > > > > > > > > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote: > > > > > > > > > > > > > > > On 07/07/2022 01:35, Jeff Xu wrote: > > > > > > a correction: > > > > > > > > > > > > ===================================== > > > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > > > any other > > > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > > > did not transition uids, start privileged, or have called > > > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > > > unchanged. > > > > > > > > > > > > Test: All passing > > > > > > > > > > > > // Base_test: 7/7 pass. > > > > > > // Fs_test 46/48 pass > > > > > > //. not ok 47 layout2_overlay.no_restriction > > > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > > > // Ptrace 8/8 pass > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > Chromium OS non-upstream patches?
Jeff Xu <jeffxu@google.com> > Jul 14, 2022, 5:35 PM (20 hours ago) > to Guenter, Mickaël, linux-security-module, Jorge, Guenter, Kees > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > enabled in chromeOS. > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > Could be. Landlock selftest currently is a user space program though, > > > IS_ENABLED will depend on the kernel header during compile time. > > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > > able to determine if overlayfs is supported by checking /sys/fs/ or > > possibly /proc/fs/. > Thanks for clarifying. > lsmod might be the one, such as: > lsmod | grep overlayfs I built a kernel with overlayfs on chromeos, and lsmod didn't give me what I wanted. /sys/fs and /proc/fs also doesn't show anything about overlayfs @Mickaël Salaün Are you OK with SKIP the overlay test when mount("overlay",...) fails in FIXTURE_SETUP() ? Mount failure can be used as an indication. Jeff On Thu, Jul 14, 2022 at 5:35 PM Jeff Xu <jeffxu@google.com> wrote: > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > enabled in chromeOS. > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > Could be. Landlock selftest currently is a user space program though, > > > IS_ENABLED will depend on the kernel header during compile time. > > > > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > > able to determine if overlayfs is supported by checking /sys/fs/ or > > possibly /proc/fs/. > > Thanks for clarifying. > > lsmod might be the one, such as: > lsmod | grep overlayfs > > > Thanks > Jeff > > > > On Thu, Jul 14, 2022 at 1:40 PM Guenter Roeck <groeck@google.com> wrote: > > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > enabled in chromeOS. > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > Could be. Landlock selftest currently is a user space program though, > > > IS_ENABLED will depend on the kernel header during compile time. > > > > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > > able to determine if overlayfs is supported by checking /sys/fs/ or > > possibly /proc/fs/. > > > > Guenter > > > > > > > > On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote: > > > > > > > > On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > > > a correction: > > > > > > > > > > > > > > ===================================== > > > > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > > > > any other > > > > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > > > > did not transition uids, start privileged, or have called > > > > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > > > > unchanged. > > > > > > > > > > > > > > Test: All passing > > > > > > > > > > > > > > // Base_test: 7/7 pass. > > > > > > > // Fs_test 46/48 pass > > > > > > > //. not ok 47 layout2_overlay.no_restriction > > > > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > > > > // Ptrace 8/8 pass > > > > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > enabled in chromeOS. > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > > > Overall, all the failure of landlock selftest seen in chromeOS are > > > > > expected, we just need to modify the test. > > > > > > > > > > Thanks > > > > > Best Regards > > > > > Jeff > > > > > > > > > > > > > > > > > > > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote: > > > > > > > > > > > > > > > > > > On 07/07/2022 01:35, Jeff Xu wrote: > > > > > > > a correction: > > > > > > > > > > > > > > ===================================== > > > > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > > > > any other > > > > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > > > > did not transition uids, start privileged, or have called > > > > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > > > > unchanged. > > > > > > > > > > > > > > Test: All passing > > > > > > > > > > > > > > // Base_test: 7/7 pass. > > > > > > > // Fs_test 46/48 pass > > > > > > > //. not ok 47 layout2_overlay.no_restriction > > > > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > > > > // Ptrace 8/8 pass > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > Chromium OS non-upstream patches?
On Fri, Jul 15, 2022 at 2:42 PM Jeff Xu <jeffxu@google.com> wrote: > > Jeff Xu <jeffxu@google.com> > > > Jul 14, 2022, 5:35 PM (20 hours ago) > > to Guenter, Mickaël, linux-security-module, Jorge, Guenter, Kees > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > > enabled in chromeOS. > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > > Could be. Landlock selftest currently is a user space program though, > > > > IS_ENABLED will depend on the kernel header during compile time. > > > > > > > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > > > able to determine if overlayfs is supported by checking /sys/fs/ or > > > possibly /proc/fs/. > > > > Thanks for clarifying. > > > > lsmod might be the one, such as: > > lsmod | grep overlayfs > > > I built a kernel with overlayfs on chromeos, and lsmod didn't give me > what I wanted. > /sys/fs and /proc/fs also doesn't show anything about overlayfs > > @Mickaël Salaün > Are you OK with SKIP the overlay test when mount("overlay",...) fails > in FIXTURE_SETUP() ? Mount failure can be used as an indication. > Maybe the error code returned from mount gives a hint. Also, how about /proc/filesystems ? Guenter > Jeff > > > > > > On Thu, Jul 14, 2022 at 5:35 PM Jeff Xu <jeffxu@google.com> wrote: > > > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > > enabled in chromeOS. > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > > Could be. Landlock selftest currently is a user space program though, > > > > IS_ENABLED will depend on the kernel header during compile time. > > > > > > > > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > > > able to determine if overlayfs is supported by checking /sys/fs/ or > > > possibly /proc/fs/. > > > > Thanks for clarifying. > > > > lsmod might be the one, such as: > > lsmod | grep overlayfs > > > > > > Thanks > > Jeff > > > > > > > > On Thu, Jul 14, 2022 at 1:40 PM Guenter Roeck <groeck@google.com> wrote: > > > > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > > enabled in chromeOS. > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > > Could be. Landlock selftest currently is a user space program though, > > > > IS_ENABLED will depend on the kernel header during compile time. > > > > > > > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > > > able to determine if overlayfs is supported by checking /sys/fs/ or > > > possibly /proc/fs/. > > > > > > Guenter > > > > > > > > > > > On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote: > > > > > > > > > > On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > > > > > a correction: > > > > > > > > > > > > > > > > ===================================== > > > > > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > > > > > any other > > > > > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > > > > > did not transition uids, start privileged, or have called > > > > > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > > > > > unchanged. > > > > > > > > > > > > > > > > Test: All passing > > > > > > > > > > > > > > > > // Base_test: 7/7 pass. > > > > > > > > // Fs_test 46/48 pass > > > > > > > > //. not ok 47 layout2_overlay.no_restriction > > > > > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > > > > > // Ptrace 8/8 pass > > > > > > > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > > enabled in chromeOS. > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > > > > > Overall, all the failure of landlock selftest seen in chromeOS are > > > > > > expected, we just need to modify the test. > > > > > > > > > > > > Thanks > > > > > > Best Regards > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote: > > > > > > > > > > > > > > > > > > > > > On 07/07/2022 01:35, Jeff Xu wrote: > > > > > > > > a correction: > > > > > > > > > > > > > > > > ===================================== > > > > > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > > > > > any other > > > > > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > > > > > did not transition uids, start privileged, or have called > > > > > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > > > > > unchanged. > > > > > > > > > > > > > > > > Test: All passing > > > > > > > > > > > > > > > > // Base_test: 7/7 pass. > > > > > > > > // Fs_test 46/48 pass > > > > > > > > //. not ok 47 layout2_overlay.no_restriction > > > > > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > > > > > // Ptrace 8/8 pass > > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > Chromium OS non-upstream patches?
> Maybe the error code returned from mount gives a hint. It returns -1 > > Also, how about > /proc/filesystems ? Yes. it has what I want: nodev overlay Thanks for your help! I can use this at runtime check. Jeff On Fri, Jul 15, 2022 at 3:42 PM Guenter Roeck <groeck@google.com> wrote: > > On Fri, Jul 15, 2022 at 2:42 PM Jeff Xu <jeffxu@google.com> wrote: > > > > Jeff Xu <jeffxu@google.com> > > > > > Jul 14, 2022, 5:35 PM (20 hours ago) > > > to Guenter, Mickaël, linux-security-module, Jorge, Guenter, Kees > > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > > > enabled in chromeOS. > > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > > > > Could be. Landlock selftest currently is a user space program though, > > > > > IS_ENABLED will depend on the kernel header during compile time. > > > > > > > > > > > > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > > > > able to determine if overlayfs is supported by checking /sys/fs/ or > > > > possibly /proc/fs/. > > > > > > > Thanks for clarifying. > > > > > > > lsmod might be the one, such as: > > > lsmod | grep overlayfs > > > > > > I built a kernel with overlayfs on chromeos, and lsmod didn't give me > > what I wanted. > > /sys/fs and /proc/fs also doesn't show anything about overlayfs > > > > @Mickaël Salaün > > Are you OK with SKIP the overlay test when mount("overlay",...) fails > > in FIXTURE_SETUP() ? Mount failure can be used as an indication. > > > > Maybe the error code returned from mount gives a hint. Also, how about > /proc/filesystems ? > > Guenter > > > Jeff > > > > > > > > > > > > On Thu, Jul 14, 2022 at 5:35 PM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > > > enabled in chromeOS. > > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > > > > Could be. Landlock selftest currently is a user space program though, > > > > > IS_ENABLED will depend on the kernel header during compile time. > > > > > > > > > > > > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > > > > able to determine if overlayfs is supported by checking /sys/fs/ or > > > > possibly /proc/fs/. > > > > > > Thanks for clarifying. > > > > > > lsmod might be the one, such as: > > > lsmod | grep overlayfs > > > > > > > > > Thanks > > > Jeff > > > > > > > > > > > > On Thu, Jul 14, 2022 at 1:40 PM Guenter Roeck <groeck@google.com> wrote: > > > > > > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > > > enabled in chromeOS. > > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > > > > Could be. Landlock selftest currently is a user space program though, > > > > > IS_ENABLED will depend on the kernel header during compile time. > > > > > > > > > > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > > > > able to determine if overlayfs is supported by checking /sys/fs/ or > > > > possibly /proc/fs/. > > > > > > > > Guenter > > > > > > > > > > > > > > On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote: > > > > > > > > > > > > On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > > > > > > > a correction: > > > > > > > > > > > > > > > > > > ===================================== > > > > > > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > > > > > > any other > > > > > > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > > > > > > did not transition uids, start privileged, or have called > > > > > > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > > > > > > unchanged. > > > > > > > > > > > > > > > > > > Test: All passing > > > > > > > > > > > > > > > > > > // Base_test: 7/7 pass. > > > > > > > > > // Fs_test 46/48 pass > > > > > > > > > //. not ok 47 layout2_overlay.no_restriction > > > > > > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > > > > > > // Ptrace 8/8 pass > > > > > > > > > > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > > > enabled in chromeOS. > > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > > > > > > > Overall, all the failure of landlock selftest seen in chromeOS are > > > > > > > expected, we just need to modify the test. > > > > > > > > > > > > > > Thanks > > > > > > > Best Regards > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 07/07/2022 01:35, Jeff Xu wrote: > > > > > > > > > a correction: > > > > > > > > > > > > > > > > > > ===================================== > > > > > > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > > > > > > any other > > > > > > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > > > > > > did not transition uids, start privileged, or have called > > > > > > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > > > > > > unchanged. > > > > > > > > > > > > > > > > > > Test: All passing > > > > > > > > > > > > > > > > > > // Base_test: 7/7 pass. > > > > > > > > > // Fs_test 46/48 pass > > > > > > > > > //. not ok 47 layout2_overlay.no_restriction > > > > > > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > > > > > > // Ptrace 8/8 pass > > > > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > > Chromium OS non-upstream patches?
On Fri, Jul 15, 2022 at 5:17 PM Jeff Xu <jeffxu@google.com> wrote: > > > Maybe the error code returned from mount gives a hint. > > It returns -1 > Sorry, I meant errno, not the return value. > > > > Also, how about > > /proc/filesystems ? > > Yes. it has what I want: > nodev overlay > Excellent. Guenter > Thanks for your help! I can use this at runtime check. > > Jeff > > > On Fri, Jul 15, 2022 at 3:42 PM Guenter Roeck <groeck@google.com> wrote: > > > > On Fri, Jul 15, 2022 at 2:42 PM Jeff Xu <jeffxu@google.com> wrote: > > > > > > Jeff Xu <jeffxu@google.com> > > > > > > > Jul 14, 2022, 5:35 PM (20 hours ago) > > > > to Guenter, Mickaël, linux-security-module, Jorge, Guenter, Kees > > > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > > > > enabled in chromeOS. > > > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > > > > > > Could be. Landlock selftest currently is a user space program though, > > > > > > IS_ENABLED will depend on the kernel header during compile time. > > > > > > > > > > > > > > > > > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > > > > > able to determine if overlayfs is supported by checking /sys/fs/ or > > > > > possibly /proc/fs/. > > > > > > > > > > Thanks for clarifying. > > > > > > > > > > lsmod might be the one, such as: > > > > lsmod | grep overlayfs > > > > > > > > > I built a kernel with overlayfs on chromeos, and lsmod didn't give me > > > what I wanted. > > > /sys/fs and /proc/fs also doesn't show anything about overlayfs > > > > > > @Mickaël Salaün > > > Are you OK with SKIP the overlay test when mount("overlay",...) fails > > > in FIXTURE_SETUP() ? Mount failure can be used as an indication. > > > > > > > Maybe the error code returned from mount gives a hint. Also, how about > > /proc/filesystems ? > > > > Guenter > > > > > Jeff > > > > > > > > > > > > > > > > > > On Thu, Jul 14, 2022 at 5:35 PM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > > > > enabled in chromeOS. > > > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > > > > > > Could be. Landlock selftest currently is a user space program though, > > > > > > IS_ENABLED will depend on the kernel header during compile time. > > > > > > > > > > > > > > > > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > > > > > able to determine if overlayfs is supported by checking /sys/fs/ or > > > > > possibly /proc/fs/. > > > > > > > > Thanks for clarifying. > > > > > > > > lsmod might be the one, such as: > > > > lsmod | grep overlayfs > > > > > > > > > > > > Thanks > > > > Jeff > > > > > > > > > > > > > > > > On Thu, Jul 14, 2022 at 1:40 PM Guenter Roeck <groeck@google.com> wrote: > > > > > > > > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > > > > enabled in chromeOS. > > > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > > > > > > Could be. Landlock selftest currently is a user space program though, > > > > > > IS_ENABLED will depend on the kernel header during compile time. > > > > > > > > > > > > > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be > > > > > able to determine if overlayfs is supported by checking /sys/fs/ or > > > > > possibly /proc/fs/. > > > > > > > > > > Guenter > > > > > > > > > > > > > > > > > On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote: > > > > > > > > > > > > > > On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote: > > > > > > > > > > > > > > > > > > a correction: > > > > > > > > > > > > > > > > > > > > ===================================== > > > > > > > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > > > > > > > any other > > > > > > > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > > > > > > > did not transition uids, start privileged, or have called > > > > > > > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > > > > > > > unchanged. > > > > > > > > > > > > > > > > > > > > Test: All passing > > > > > > > > > > > > > > > > > > > > // Base_test: 7/7 pass. > > > > > > > > > > // Fs_test 46/48 pass > > > > > > > > > > //. not ok 47 layout2_overlay.no_restriction > > > > > > > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > > > > > > > // Ptrace 8/8 pass > > > > > > > > > > > > > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > > > Chromium OS non-upstream patches? > > > > > > > > > > > > > > > > > > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not > > > > > > > > enabled in chromeOS. > > > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount > > > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP. > > > > > > > > > > > > > > > > > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ? > > > > > > > > > > > > > > > Overall, all the failure of landlock selftest seen in chromeOS are > > > > > > > > expected, we just need to modify the test. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Best Regards > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On 07/07/2022 01:35, Jeff Xu wrote: > > > > > > > > > > a correction: > > > > > > > > > > > > > > > > > > > > ===================================== > > > > > > > > > > case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to > > > > > > > > > > any other > > > > > > > > > > process running under the same uid, as long as it is dumpable (i.e. > > > > > > > > > > did not transition uids, start privileged, or have called > > > > > > > > > > prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is > > > > > > > > > > unchanged. > > > > > > > > > > > > > > > > > > > > Test: All passing > > > > > > > > > > > > > > > > > > > > // Base_test: 7/7 pass. > > > > > > > > > > // Fs_test 46/48 pass > > > > > > > > > > //. not ok 47 layout2_overlay.no_restriction > > > > > > > > > > //. not ok 48 layout2_overlay.same_content_different_file > > > > > > > > > > // Ptrace 8/8 pass > > > > > > > > > > > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other > > > > > > > > > Chromium OS non-upstream patches?
On 16/07/2022 23:45, Guenter Roeck wrote: > On Fri, Jul 15, 2022 at 5:17 PM Jeff Xu <jeffxu@google.com> wrote: >> >>> Maybe the error code returned from mount gives a hint. >> >> It returns -1 >> > Sorry, I meant errno, not the return value. > >>> >>> Also, how about >>> /proc/filesystems ? >> >> Yes. it has what I want: >> nodev overlay >> > Excellent. > > Guenter > >> Thanks for your help! I can use this at runtime check. >> >> Jeff >> >> >> On Fri, Jul 15, 2022 at 3:42 PM Guenter Roeck <groeck@google.com> wrote: >>> >>> On Fri, Jul 15, 2022 at 2:42 PM Jeff Xu <jeffxu@google.com> wrote: >>>> >>>> Jeff Xu <jeffxu@google.com> >>>> >>>>> Jul 14, 2022, 5:35 PM (20 hours ago) >>>>> to Guenter, Mickaël, linux-security-module, Jorge, Guenter, Kees >>>>>> On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote: >>>>>>> >>>>>>>>>> Hmm, well, it is not related to Yama then. Could it be linked to other >>>>>>>>>> Chromium OS non-upstream patches? >>>>>>>>> >>>>>>>>> >>>>>>>>> fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not >>>>>>>>> enabled in chromeOS. >>>>>>>>> If there is a reliable way of detecting OVERLAYFS (checking mount >>>>>>>>> overlayfs is successful ? ), this is a good candidate to add SKIP. >>>>>>>>> >>>>>>> >>>>>>>> IS_ENABLED(CONFIG_OVERLAY_FS) ? >>>>>>> >>>>>>> Could be. Landlock selftest currently is a user space program though, >>>>>>> IS_ENABLED will depend on the kernel header during compile time. >>>>>>> >>>> >>>> >>>> >>>>>> Ah, sorry, I thought it was an in-kernel test. Userspace should be >>>>>> able to determine if overlayfs is supported by checking /sys/fs/ or >>>>>> possibly /proc/fs/. >>>> >>>> >>>>> Thanks for clarifying. >>>> >>>> >>>>> lsmod might be the one, such as: >>>>> lsmod | grep overlayfs >>>> >>>> >>>> I built a kernel with overlayfs on chromeos, and lsmod didn't give me >>>> what I wanted. >>>> /sys/fs and /proc/fs also doesn't show anything about overlayfs >>>> >>>> @Mickaël Salaün >>>> Are you OK with SKIP the overlay test when mount("overlay",...) fails >>>> in FIXTURE_SETUP() ? Mount failure can be used as an indication. In a normal scenario, all configurations in tools/testing/selftests/landlock/config should be enabled, but I think it makes sense for some use cases like chromeOS to be able to not fail if overlayfs is not supported. Please patch FIXTURE_SETUP(layout2_overlay) to skip these tests if the related filesystem string is present (with or without "nodev") in /proc/filesystems . You can create a is_filesystem_supported(const char *filesystem) helper before prepare_layout() for this check, we'll need it for future tests. >>>> >>> >>> Maybe the error code returned from mount gives a hint. Also, how about >>> /proc/filesystems ? >>> >>> Guenter
diff --git a/tools/testing/selftests/landlock/ptrace_test.c b/tools/testing/selftests/landlock/ptrace_test.c index c28ef98ff3ac..ef2d36f56764 100644 --- a/tools/testing/selftests/landlock/ptrace_test.c +++ b/tools/testing/selftests/landlock/ptrace_test.c @@ -226,6 +226,44 @@ FIXTURE_TEARDOWN(hierarchy) { } +int open_sysfs(const char *path, int flags, int *fd) +{ + *fd = open(path, flags); + + if (fd < 0) + return -1; + + return 0; +} + +int read_sysfs_int_fd(int fd, int *val) +{ + char buf[2]; + + if (read(fd, buf, sizeof(buf)) < 0) + return -1; + + buf[sizeof(buf) - 1] = '\0'; + *val = atoi(buf); + return 0; +} + +int read_sysfs_int(const char *path, int *val) +{ + int fd; + + if (open_sysfs(path, O_RDONLY, &fd) != 0) + return -1; + + if (read_sysfs_int_fd(fd, val) != 0) { + close(fd); + return -1; + } + + close(fd); + return 0; +} + /* Test PTRACE_TRACEME and PTRACE_ATTACH for parent and child. */ TEST_F(hierarchy, trace) { @@ -235,6 +273,17 @@ TEST_F(hierarchy, trace) char buf_parent; long ret; + int ptrace_val; + + ASSERT_EQ(0, read_sysfs_int("/proc/sys/kernel/yama/ptrace_scope", + &ptrace_val)); + if (ptrace_val != 0) { + /* + * Yama's scoped ptrace is presumed disabled. If enabled, skip. + */ + SKIP(return, "yama is enabled, skip current test"); + } + /* * Removes all effective and permitted capabilities to not interfere * with cap_ptrace_access_check() in case of PTRACE_MODE_FSCREDS.