| 1 |
On Sunday, 6 December 2020 07:55:29 GMT Martin Vaeth wrote: |
| 2 |
> Dale <rdalek1967@×××××.com> wrote: |
| 3 |
> > It sounds like a rather rare problem. Maybe even only during boot up. |
| 4 |
> |
| 5 |
> It is a non-existent problem on openrc if you clean /tmp and /var/tmp |
| 6 |
> on boot (which you should do if you use opentmp): |
| 7 |
> |
| 8 |
> The purpose of opentmpfiles is to fill these directories with |
| 9 |
> certain data during boot, and when run only during boot |
| 10 |
> (as it is supposed to be) there is nothing wrong with it. |
| 11 |
> |
| 12 |
> The situation is different for systemd which runs tmpfiles |
| 13 |
> periodically to clean up data from /tmp and /var/tmp |
| 14 |
> (something which should argueably be done by a dedicated tool |
| 15 |
> instead of putting two different functionalities into the same |
| 16 |
> tool - the usual systemd misconception of trying to be monolithic). |
| 17 |
> |
| 18 |
> There is a certain danger if you install a new package whose |
| 19 |
> ebuild processes on installation a certain tmpfiles.conf |
| 20 |
> which writes into one of the world-writable directories /tmp or |
| 21 |
> /var/tmp: Such an ebuild does an inherently unsafe thing during |
| 22 |
> installation (but it doesn't matter whether it does this using |
| 23 |
> opentmpfiles or by calling the shell commands manually), and I |
| 24 |
> would not hesitate to file a bug against such an ebuild. |
| 25 |
|
| 26 |
|
| 27 |
Given M.Orlitzky's comments and discussions with systemd devs he shared, |
| 28 |
what's the optimal solution for OpenRC users, who want to avoid systemd? |
| 29 |
|
| 30 |
Rely on ebuild creators and maintainer checks to guard against these inherent |
| 31 |
vulnerabilities? Or install --oneshot systemd-tmpfiles, at least temporarily |
| 32 |
until an OpenRC solution is cooked? |
Archives