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. > 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? > > > > +The systemd maintainer has dismissed this as something people should > > > > +simply ignore[1] and has no interest in trying to avoid it by > > > > +proactively checking the kernel version, so people can safely assume > > > > +that they will never see this version check commit upstream. > > > > + > > > > +However, as can be seen above, telling people to just ignore it is not > > > > +an option, as we'll end up answering the same question and dealing with > > > > +the same bug over and over again. > > > > + > > > > +The commit that triggers this is systemd v247-rc1~378^2~3 -- so any > > > > +systemd 247 and above plus kernel v5.7 or older will need this. > > > > + > > > > +[1] > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsystemd%2Fsystemd%2Fissues%2F16896&data=04%7C01%7CLuca.Boccassi%40microsoft.com%7Ce972c325854743b67f0b08d8b9647bf1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637463188548752517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=r%2FCh5m3ZLautkN1PLg99HqGdfl4VXqiNjJUsJhDPmCI%3D&reserved=0 > > > > + > > > > +Upstream-Status: Actively hostile > > > > > > The status needs to be > > > > > > Upstream-Status: Denied [Actively hostile > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsystemd%2Fsystemd%2Fissues%2F16896&data=04%7C01%7CLuca.Boccassi%40microsoft.com%7Ce972c325854743b67f0b08d8b9647bf1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637463188548752517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=r%2FCh5m3ZLautkN1PLg99HqGdfl4VXqiNjJUsJhDPmCI%3D&reserved=0] > > > > > > (so our tools have an idea of what status patches are in) > > > > Paul, please, let's avoid loaded language - Denied is fine by itself > > and conveys what it needs to. I understand it can be frustrating when > > upstream maintainers do not agree with user assessments, but the linked > > discussion was polite and professional and there's no need to call it > > "hostile". > > Normally I'd agree with you, but it isn't just this one thread/instance, > but instead *years* of continued "my way or the highway" behaviour > demonstrated by systemd on various lists like LKML, for all to see. In > any case, in the interest of not breaking existing tooling, and getting > the fix to our users, I am fine with it being changed to simply be: > > Upstream-Status: Denied > [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsystemd%2Fsystemd%2Fissues%2F16896&data=04%7C01%7CLuca.Boccassi%40microsoft.com%7Ce972c325854743b67f0b08d8b9647bf1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637463188548752517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=r%2FCh5m3ZLautkN1PLg99HqGdfl4VXqiNjJUsJhDPmCI%3D&reserved=0] That's not entirely accurate, but let's leave it at that. -- 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 (#146829): https://lists.openembedded.org/g/openembedded-core/message/146829 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] -=-=-=-=-=-=-=-=-=-=-=-
