Hi Lorenzo. Lorenzo - 11.05.24, 02:16:15 CEST: > On Tue, 07 May 2024 15:08:37 +0200 > Martin Steigerwald <mar...@lichtvoll.de> wrote: > >[...] > > Are init scripts supposed to be started with PATH variable set up and > > exported or not? How is it done with SysVInit? I bet it would be best > > to match as close as possible what SysVInit is doing to be as > > compatible as possible. > > I checked this and in sysvinit you don't have this bug because during > boot sysvscripts are run via /etc/ini.d/rc script, and there is an > 'export PATH' there. It could probably be triggered by calling the > script directly during runtime. > In runit we are calling scripts directly in stage1 so we have this bug
I see. > > Otherwise it might be challenging to chase and find all the corner > > cases with existing setups. And as there is no issue initializing the > > network in the container with SysVInit instead of Runit used as PID > > 1, I'd consider a change in Runit. At least it could be challenging > > to find whether networking inside a container is the only thing that > > breaks. > > I want to dig this further, I don't recall broken network under docker > and I don't think is broken under qemu, but I can be wrong or remember > something from before /etc/init.d/rc usage was dropped from stage1 Could have something to do with Incus / LXD then. I used Incus in Devuan testing (upcoming Excalibur), which is based on Debian testing (upcoming Trixie). In case it is helpful for you I could post a step to step guide for a minimal Incus setup and/or at least some pointers. > > > > I just wonder why stage 2 contains /usr/local bin directories. I > > > > think that should not be the case. Shall I report this as a > > > > different issue? > > > > > > PATH is passed to env call for runsvdir, so I guess one can exec a > > > bin from local as runscript (not sure) without setting the PATH. I > > > can't think of other use cases.. […] > > Hmm, I get that. I am just a bit concerned as it may be a security > > issue. > > not urgent, but could you elaborate this (security implications)? is > something like an attacker placing a modified foo in /usr/local/ that > overrides the legit foo in /usr/bin or is something else? one still > needs root privileges to write to /usr/local.. Good question. It is how I learned it. :) Yes, usually /usr/local is only writable by root, however… maybe an admin or user with root privileges put some own version of say coreutils or whatever in there for whatever reason and forgot about it. And later on it has some security whole that remains unpatched. With PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/sbin:/usr/bin:/bin a vulnerable command might be picked up from /usr/local's s(bin) as it is even before the regular system managed (s)bin directories. Yes, you can consider that an user error, but there might even be other scenarios, like an user or admin installed some special version of ls or some other command in there as they prefer it. Even if the behavior or such a special replacement command is only slightly different than of the original system default command it could cause all kinds of trouble. I believe this may be some of the reasoning behind the rule I learned about to only have system directories in PATH for system provided scripts and programs. It at least appears to me like the approach of least surprise. /usr/local, only root-writable or not, is user managed. There could be anything in there causing all kinds of various trouble. A compromise here would be to change the path like this: PATH=/usr/sbin:/sbin:/usr/bin:/bin:/usr/local/sbin:/usr/local/bin With that order at least a modified "ls" from /usr/local/bin would not be picked up as there is a system managed one available. But a command that is not available in system managed directories would still be picked up from /usr/local directories. As one point of practical experience, I changed path to PATH=/sbin:/usr/sbin:/bin:/usr/bin in one Incus managed Devuan container which runs a Wordpress blog on Apache and PHP FPM and I see no issues. However as I also don't have anything in /usr/local that is to be expected. One approach could be to just change the path to the above system managed directories only path, add some NEWS.Debian entry about it and see whether someone complains :) I do think this discussion belongs into a different bug report though. I am willing to open a low priority report about this and include the previous relevant discussion to it, so it does not get lost and you can take your time to ponder about it. There is no need to rush it. Have a great weekend! -- Martin
