Building on 6.2.3. * Messages for package app-containers/docker-23.0.1: * CONFIG_MEMCG_SWAP: is not set when it should be. * CONFIG_LEGASY_SYSCALL_emulate: is not set when it should be. CONFIG_MEMCG_SWAP is no longer available since kernel 6.1, and what is 'CONFIG_LEGASY_SYSCALL_emulate' supposed to be? Reproducible: Always
Also a type error: LEGASY -> LEGACY mine gives me these three errors impossibile to find in kernel .confic * CONFIG_MEMCG: is not set when it should be. * CONFIG_MEMCG_SWAP: is not set when it should be. * CONFIG_LEGASY_SYSCALL_emulate: is not set when it should be. [ !! ]
(In reply to Florian Faber from comment #0) > Building on 6.2.3. Same kernel, same warnings and also: * CONFIG_SECURITY_SELINUX: is not set when it should be. * CONFIG_SECURITY_APPARMOR: is not set when it should be. When docker is compiled with USE="-apparmor -selinux". (In reply to Silvio from comment #1) > mine gives me these three errors impossibile to find in kernel .confic > * CONFIG_MEMCG: is not set when it should be. Please specify your kernel version, this feature is present in kernel 6.2.
I am also seeing 3 (allegedly) missing kernel options being reported by app-containers/docker-23.0.1: * CONFIG_MEMCG_SWAP: is not set when it should be. * CONFIG_LEGASY_SYSCALL_emulate: is not set when it should be. * CONFIG_RT_GROUP_SCHED: is not set when it should be. I'm running sys-kernel/gentoo-kernel-bin-6.2.3 / virtual/dist-kernel-6.2.3
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=03e62a35cc62d4651398e12b92a6a88387b65a2b commit 03e62a35cc62d4651398e12b92a6a88387b65a2b Author: Sam James <sam@gentoo.org> AuthorDate: 2023-03-11 19:22:39 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-03-11 19:23:12 +0000 app-containers/docker: fix (some) kernel check options This doesn't fix all of them, just the misspellings of VSYSCALL. Bug: https://bugs.gentoo.org/900845 Signed-off-by: Sam James <sam@gentoo.org> app-containers/docker/docker-23.0.1.ebuild | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
Why should CONFIG_LEGACY_VSYSCALL_EMULATE be set anyway? I control what runs in my docker containers, and it is most certainly no crappy ancient binaries. This setting would also conflict with GENTOO_KERNEL_SELF_PROTECTION.
* CONFIG_MEMCG: is not set when it should be. * CONFIG_RT_GROUP_SCHED: is not set when it should be. These 2 do exist in linux-6.2.3-gentoo * CONFIG_MEMCG_SWAP: is not set when it should be. This one doesn't since v6.1-rc where it was removed with this commit: https://github.com/torvalds/linux/commit/e55b9f96860f6c6026cff97966a740576285e07b * CONFIG_LEGACY_VSYSCALL_EMULATE Is also gone since 5.19-rc1 where it was removed with this commit: https://github.com/torvalds/linux/commit/bf00745e7791fe2ba7941aeead8528075a158bbe Corresponding section in moby: https://github.com/moby/moby/blob/master/contrib/check-config.sh#L279 seems to accept CONFIG_LEGACY_VSYSCALL_EMULATE only if it's there (not asking for it to be enabled on kernels which don't support it).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f78eaca943ed47dbea9a7c44e9f438aa3575438 commit 6f78eaca943ed47dbea9a7c44e9f438aa3575438 Author: William Hubbs <williamh@gentoo.org> AuthorDate: 2023-03-14 16:44:19 +0000 Commit: William Hubbs <williamh@gentoo.org> CommitDate: 2023-03-14 16:49:53 +0000 app-containers/docker: more kernel option fixes - put SECURITY_SELINUX and SECURITY_APPARMOR behind the appropriate use flags - put MEMCG_SWAP and LEGACY_SYSCALL_EMULATE behind kernel version checks Bug: https://bugs.gentoo.org/900845 Signed-off-by: William Hubbs <williamh@gentoo.org> app-containers/docker/docker-23.0.1.ebuild | 37 +++++++++++++++++++++++------- 1 file changed, 29 insertions(+), 8 deletions(-)
Please resync and rebuild then let me know if this cleans up the messages you were seeing. Thanks, William
No warnings shown for me with 6.2.6-gentoo, thanks!
* CONFIG_LEGACY_VSYSCALL_NONE: should not be set. But it is. [ !! ] This is not acceptable. There is no need to ask for this setting.
I'm asking you to disable that setting,not enable it. But, it looks like the earliest glibc we now have in the tree is 2.19, so I may not need to worry about it any longer. I'll take a look and see when glibc-2.13 was removed; I think it was pretty recent.
I know what you are asking for, I can read. Disabling NONE would make *all* systems less secure and violates GENTOO_KERNEL_SELF_PROTECTION. That one person that wants to run binary only software from the pleistocene can enable it, but do not force everybody else.
I looked into this a bit and it would seem that there is a simple ebuild typo which is leading to this misleading warning. The ebuild sets: WARNING_LEGACY_SYSCALL_NONE="CONFIG_LEGACY_VSYSCALL_NONE enabled: \ Containers with <=glibc-2.13 will not work" but it's missing the "V" in VSYSCALL, so it reverts to the generic warning for this config check instead. If we fix the typo, it goes from * CONFIG_LEGACY_VSYSCALL_NONE: should not be set. But it is. (non-fatal eerror call, red with [!!]) to * CONFIG_LEGACY_VSYSCALL_NONE enabled: Containers with <=glibc-2.13 will not work (non-fatal ewarn call, yellow) I believe William will have a fix for this incoming soon.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=18749359ef244ab3c82a32a66c8cbf9884acc1a4 commit 18749359ef244ab3c82a32a66c8cbf9884acc1a4 Author: William Hubbs <williamh@gentoo.org> AuthorDate: 2023-03-15 17:33:39 +0000 Commit: William Hubbs <williamh@gentoo.org> CommitDate: 2023-03-15 17:39:02 +0000 app-containers/docker: typo fix for LEGACY_VSYSCALL_NONE warning The warning was not assigned to the proper configuration check. This commit fixes that issue which results in a better warning message. Bug: https://bugs.gentoo.org/900845 Signed-off-by: William Hubbs <williamh@gentoo.org> app-containers/docker/docker-23.0.1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Let me know if that makes things more clear for you.
I've custom/hardened kernel config and installed 23.0.1 just fine now, so probably this issue is completed. Meanwhile, there is another issue with 23.0.1: shell completion needs to be updated. But I'll open another issue for this now.
