ujail: bug or feature ?

[e9hack]

Am 26.03.2021 um 12:09 schrieb Daniel Golle:
> 
> On Fri, Mar 26, 2021 at 10:54:32AM +0100, e9hack wrote:
>> Am 26.03.2021 um 10:17 schrieb Daniel Golle:
>>> On Fri, Mar 26, 2021 at 09:32:33AM +0100, e9hack wrote:
>>>> Hi,
>>>>
>>>> a program run by ujail gets a PID of 1. The real PID is different. If such a program generates a PID file by its own and the PID from that file is used by a script that is not run by ujail, then any operation will be performed with the wrong PID, which is the PID of /sbin/procd in the real world.
>>>>
>>>> Is this the expected behaviour?
>>>
>>> Yes, this is expected behaviour as the program run by ujail ends up in
>>> a new PID namespace (so that it cannot "see" other running processes).
>>> If this presents a problem to your use-case, I can add an option to
>>> have a the process live in the root PID namespace instead (ie. trade
>>> some isolation for interoperatibility).
>>>
>>
>> I use a modified init script for dnsmasq and let dnsmasq generate the PID file. Another script is using this PID file and this doesn't work as I switched to ujail. I have changed it now. The PID file is generated via "procd_set_param pidfile ...".
> 
> `procd_set_param pidfile` should work with ujail, however, it will give
> you the PID of `ujail` rather than the PID of the jailed process.
> There also a jail parameter `pidfile` which writes a pidfile for the
> jailed process itself which I introduced for use with `uxc`, however,
> I haven't included that in procd.sh for jailed services yet, because
> there was no need for that until now.
> (signals other than SIGKILL are forwarded to the jailed process, ujail
> instance terminates in case of jailed process terminating, ... so in
> most cases you are fine when using the PID of the corresponding ujail
> process)
> 

I'm sending to one dnsmasq instance SIGUSR1 via a cron job every 6 hours. I didn't really verify the PID, but I did check for the result in the log file.