[systemd-devel] I want to run systemd inside of a locked down base docker container

[Daniel J Walsh]

On 02/10/2016 05:21 PM, Lennart Poettering wrote:
> On Wed, 10.02.16 16:43, Daniel J Walsh (dwalsh at redhat.com) wrote:
>
>>>>> I don't see why one would want to mask systemd-logind.service. If you
>>>>> permit logins and PAM at all, you really need that. 
>>>> If I wanted to add a login program I could enable/unmask these.
>>>> No one runs docker containers as login services, that would require
>>>> getty. 
>>> Well, "machinectl shell", "cron" and all those things do PAM... In
>>> fact the fact that "machinectl shell" goes through PAM and registers
>>> with logind through that is one of the major benefits over naked
>>> "nsenter".
>> I wonder if any of these work correctly inside of a docker container?
>>
>> Can these be customized or do they require systemd as pid 1 inside of
>> the container.  Docker has a "docker exec"
> No, "machinectl shell" requires PID 1 in the container to be systemd.
>
> Unlike "nsenter" (and docker exec, as I presume), "machinectl shell"
> will not try to take a process from the host and patch around in its
> process attributes until it appears to be a process from within the
> container (by joining namespaces, cgroups, uids, gids, selinux labels,
> audit creds, …). It will instead allocate a pty in the container and
> then use ask systemd inside the container using the "transient units"
> API to spawn a shell on it. It then does nothing else than forward
> data between this pty and the tty it was invoked from. 
>
> This way the only processes you see in the container have actually
> been started by systemd inside the container. They are properly
> tracked and maintained like any other process invoked in the container
> by the systemd instance that is running it. They inherit the process
> attributes from PID 1 in the container, and the PPID reported for them
> will actually be 1 as it should. – They are not these weird alien
> processes like nsenter creates that are half-way part of the host
> system and half-way member of the container, for which PPID returns 0
> in the container, because they actually don't have a parent process
> inside of the container.
>
> Long story short: "machinectl shell" should work fine even with docker
> containers – as long as systemd runs as PID 1 in them.
>
>>> I added this to the TODO list now.
>> Sounds fine with me.  I went back to the original container and I can
>> remove all of the other modifications, I can live with the warnings at the
>> beginning and remove the /etc/fstab.  We just need to get this into more
>> people hands to see what happens and what breaks. 
> Quite frankly, I don't understand why /etc/fstab is populated at all
> on Fedora by default. It should only exists if there are actual
> external file systems configured in it, and otherwise just not exist.
>
>> This is what I am seeing now with just /etc/fstab removed.
>>
>> Welcome to Fedora 23 (Twenty Three)!
>>
>> Set hostname to <654f7872d331>.
>> dev-hugepages.mount: Cannot add dependency job, ignoring: Unit dev-hugepages.mount is masked.
>> sys-fs-fuse-connections.mount: Cannot add dependency job, ignoring: Unit sys-fs-fuse-connections.mount is masked.
>> systemd-remount-fs.service: Cannot add dependency job, ignoring: Unit systemd-remount-fs.service is masked.
>> systemd-logind.service: Cannot add dependency job, ignoring: Unit systemd-logind.service is masked.
>> getty.target: Cannot add dependency job, ignoring: Unit getty.target
>> is masked.
> Again, there should be no need to mask dev-hugepages.mount and
> getty.target at all. And if you drop /etc/fstab there's no need to
> mask systemd-remount-fs.target either. Please unmask those three
> units!
>
> As soon as my patch to add the ConditionCapability= check to
> sys-fs-fuse-connections.mount you should also be able to unmask that
> unit and get a clean boot.
>
> Lennart
>
I am now masking nothing, just removing /etc/fstab.   We will probably
need to back port the dev-hugepages.mount fix
to rhel7 at some point.