landlock syscalls missing?
by ZlatkO from LinuxQuestions.org on (#6MHWG)
Hi,
When trying to compile tracker-miners-3.7.x without "-D landlock=disabled", meson complains that ...
Code:meson.build:195:4: ERROR: Problem encountered: Landlock was auto-enabled in build options, but is disabled in the kernel..., which is not quite true (this is a custom built 6.6.30 LTS kernel):
Code:[zlatko@disclosure:~]$ grep -i landlock /boot/config
CONFIG_SECURITY_LANDLOCK=y
CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity"However, it appears that all of the landlock related syscalls are indeed missing from glibc's /usr/include/bits/syscall.h:
Code:[root@disclosure:~]# grep -r SYS_landlock /usr/include/
[root@disclosure:~]#For reference, here's the output of the same command on a FC39 system:
Code:[root@wasser:~]# grep -r SYS_landlock /usr/include/
/usr/include/bits/syscall.h:# define SYS_landlock_add_rule __NR_landlock_add_rule
/usr/include/bits/syscall.h:# define SYS_landlock_create_ruleset __NR_landlock_create_ruleset
/usr/include/bits/syscall.h:# define SYS_landlock_restrict_self __NR_landlock_restrict_selfNow, given that ...
1. landlock has been available since kernel 5.13, and Slackware-15.0 initially shipped with 5.15;
2. there appear to be landlock related patches back to at least glibc-2.28, and Slackware-15.0 ships with 2.33;
3. there don't seem to be any bits & bobs explicitly disabling landlock in glibc's SlackBuild script;
... I wonder where the landlock related syscalls have gone? The only reason I could imagine is that they only get included/shipped/exported to "bits/syscall.h" if glibc is built/compiled/packaged on a kernel that actually has CONFIG_SECURITY_LANDLOCK=y enabled, could that be the case? And yes, I know I could do that, but I'd rather not have to rebuild glibc on my system just to find out ... ;)
Thanks for listening,
Thomas
When trying to compile tracker-miners-3.7.x without "-D landlock=disabled", meson complains that ...
Code:meson.build:195:4: ERROR: Problem encountered: Landlock was auto-enabled in build options, but is disabled in the kernel..., which is not quite true (this is a custom built 6.6.30 LTS kernel):
Code:[zlatko@disclosure:~]$ grep -i landlock /boot/config
CONFIG_SECURITY_LANDLOCK=y
CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity"However, it appears that all of the landlock related syscalls are indeed missing from glibc's /usr/include/bits/syscall.h:
Code:[root@disclosure:~]# grep -r SYS_landlock /usr/include/
[root@disclosure:~]#For reference, here's the output of the same command on a FC39 system:
Code:[root@wasser:~]# grep -r SYS_landlock /usr/include/
/usr/include/bits/syscall.h:# define SYS_landlock_add_rule __NR_landlock_add_rule
/usr/include/bits/syscall.h:# define SYS_landlock_create_ruleset __NR_landlock_create_ruleset
/usr/include/bits/syscall.h:# define SYS_landlock_restrict_self __NR_landlock_restrict_selfNow, given that ...
1. landlock has been available since kernel 5.13, and Slackware-15.0 initially shipped with 5.15;
2. there appear to be landlock related patches back to at least glibc-2.28, and Slackware-15.0 ships with 2.33;
3. there don't seem to be any bits & bobs explicitly disabling landlock in glibc's SlackBuild script;
... I wonder where the landlock related syscalls have gone? The only reason I could imagine is that they only get included/shipped/exported to "bits/syscall.h" if glibc is built/compiled/packaged on a kernel that actually has CONFIG_SECURITY_LANDLOCK=y enabled, could that be the case? And yes, I know I could do that, but I'd rather not have to rebuild glibc on my system just to find out ... ;)
Thanks for listening,
Thomas