On Sunday, 6 December 2020 07:55:29 GMT Martin Vaeth wrote: > Dale <rdalek1...@gmail.com> wrote: > > It sounds like a rather rare problem. Maybe even only during boot up. > > It is a non-existent problem on openrc if you clean /tmp and /var/tmp > on boot (which you should do if you use opentmp): > > The purpose of opentmpfiles is to fill these directories with > certain data during boot, and when run only during boot > (as it is supposed to be) there is nothing wrong with it. > > The situation is different for systemd which runs tmpfiles > periodically to clean up data from /tmp and /var/tmp > (something which should argueably be done by a dedicated tool > instead of putting two different functionalities into the same > tool - the usual systemd misconception of trying to be monolithic). > > There is a certain danger if you install a new package whose > ebuild processes on installation a certain tmpfiles.conf > which writes into one of the world-writable directories /tmp or > /var/tmp: Such an ebuild does an inherently unsafe thing during > installation (but it doesn't matter whether it does this using > opentmpfiles or by calling the shell commands manually), and I > would not hesitate to file a bug against such an ebuild.
Given M.Orlitzky's comments and discussions with systemd devs he shared, what's the optimal solution for OpenRC users, who want to avoid systemd? Rely on ebuild creators and maintainer checks to guard against these inherent vulnerabilities? Or install --oneshot systemd-tmpfiles, at least temporarily until an OpenRC solution is cooked?
signature.asc
Description: This is a digitally signed message part.
