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. > > > 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 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. > > > > > > +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. I'm with Paul :D Bruce > > -- > Kind regards, > Luca Boccassi > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#146833): https://lists.openembedded.org/g/openembedded-core/message/146833 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] -=-=-=-=-=-=-=-=-=-=-=-
