On Fri, 2021-01-15 at 11:07 -0500, Bruce Ashfield wrote: > On Fri, Jan 15, 2021 at 10:37 AM Luca Boccassi via > lists.openembedded.org > <luca.boccassi=microsoft....@lists.openembedded.org> wrote: > > On Fri, 2021-01-15 at 09:47 -0500, Paul Gortmaker wrote: > > > [Re: [PATCH] systemd: dont spew hidepid mount errors for kernels < v5.8] > > > On 15/01/2021 (Fri 09:57) Luca Boccassi wrote: > > > > > > > On Fri, 2021-01-15 at 08:37 +0000, Richard Purdie wrote: > > > > > On Fri, 2021-01-15 at 00:26 -0500, Paul Gortmaker wrote: > > > > > > Recent systemd started using ascii args to "hidepid=" mount options > > > > > > for proc fs - unconditionally -- even though kernels older than v5.8 > > > > > > emit an error message on each attempt: > > > > > > > > > > > > root@qemux86-64:~# cat /proc/version > > > > > > Linux version 5.4.87-yocto-standard (oe-user@oe-host) (gcc version > > > > > > 10.2.0 (GCC)) #1 SMP PREEMPT Fri Jan 8 01:47:13 UTC 2021 > > > > > > root@qemux86-64:~# dmesg|grep proc: > > > > > > [ 29.487995] proc: Bad value for 'hidepid' > > > > > > [ 43.170571] proc: Bad value for 'hidepid' > > > > > > [ 44.175615] proc: Bad value for 'hidepid' > > > > > > [ 46.213300] proc: Bad value for 'hidepid' > > > > > > root@qemux86-64:~# > > > > > > > > Wouldn't it be better to patch the kernel to downgrade that message to > > > > debug level? > > > > > > The problem is that the breakage is forced upon older kernels, so you'd > > > have to effectively mainline that kind of "fix" to v5.12 (where there is > > > no problem) and then you could in theory request it for v5.4 linux-stable > > > according to "stable rules". > > > > The patch could be downstream for older kernels, just like this one is. > > With the difference that it would be temporary. > > But the coverage is impossible, since there are so many > different kernel trees. So a kernel solution is a non-starter.
IMHO a long term solution can only go through the kernel. There will be more instances like this in the future, given the fundamental issue is the lack of a clear EOPNOTSUPP-like interface. I realise the mount interface is ancient at this point, and difficult to change. We are keeping an eye on the evolution of the new interface, but it's not there yet (eg: no read-only bind mounts). > > > Besides, if something with root/mount priv. is consistently trying to > > > drive a square peg into a round hole - by trying to mount something and > > > failing -- it should be something that a sysadmin would want to > > > investigate. Which is precisely why I am here now. I think burying it > > > at debug level is counterproductive to that. > > > > Well the real issue is that there's no way to get a clean "we don't > > support this option" out of certain kernel APIs, so one has to guess > > and see what happens. Sometimes it's even worse, and flags like > > NOSYMFOLLOW get silently ignored if they are not supported, which is > > not great for security-related settings... > > > > Anyway, these warnings only appear if ProtectProc and/or ProcSubset are > > set to something other than the default value. Why not simply add a > > top-level drop-in in /etc that forces them to be disabled in all > > services if you have an older kernel? Something like this: > > > > /etc/systemd/system/service.d/10-override-protect-proc.conf > > [Service] > > ProtectProc=default > > ProcSubset=all > > > > And then you can drop it when you upgrade your kernel. Isn't this a > > better option than taking on permanent technical debt? > > That's even more fiddly than Paul's patch. It relies on much more > of someone's distro configuration. But what is the combination of a kernel version + systemd version if not someone's distro configuration? I mean, it could even be added dynamically by the poky recipe at build time, given the kernel version is known at that point. Surely a three lines piece of configuration is better to handle than a downstream patch? > But it is true that you can throw it away eventually, assuming > someone actually knows that it is there. > > I wouldn't call this patch much of a technical debt, but if it starts > gumming up systemd upgrades, it's easy to revisit. It's in a security-critical area that we are constantly improving and expanding. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#146834): https://lists.openembedded.org/g/openembedded-core/message/146834 Mute This Topic: https://lists.openembedded.org/mt/79695930/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
