[systemd-devel] sshd inside in a nspawn container

[Lennart Poettering]

On Sun, 03.04.11 16:59, Albert Strasheim (fullung at gmail.com) wrote:

> Hello all
> 
> I've been working on a systemd configuration to do integration tests
> with a few services inside a nspawn container.
> 
> Among these, I'm trying to get sshd going using the units here as a
> starting point:
> 
> http://0pointer.de/public/systemd-units/
> 
> Unfortunately, it seems the nspawn container is a bit restrictive for
> what sshd wants to do.
> 
> Firstly, I had problems with auditd:
> 
> auditd: Error setting audit daemon pid (Operation not permitted)
> auditd: Started dispatcher: /sbin/audispd pid: 20
> auditd: Error setting audit daemon pid (Operation not permitted)
> auditd: Unable to set audit pid, exiting
> auditd: The audit daemon is exiting.

We do not allow any audit related operations in the nspawn container
(the CAP_AUDIT_CONTROL, CAP_AUDIT_WRITE caps are dropped) since the
audit subsystem is not virtualized for containers and the messages from
the container would show up in the normal audit logs, as if they were
generated in the host system.

This shouldn't be much of a problem normally, as audit is not really
necessary, and apps failing to write an audit record should just warn
and go on.

> and then sshd would error out with:
> 
> sshd: error: cannot write into audit

Is this really a fatal error? Normally it should just log this and go
on. I'd recommend filing a bug here. 

> Accepted password for root from 127.0.0.1 port 55879 ssh2
> fatal: mm_request_receive: read: Connection reset by peer
> pam_loginuid(sshd:session): set_loginuid failed
> pam_systemd(sshd:session): Failed to get user data.
> pam_unix(sshd:session): session opened for user root by (uid=0)
> error: PAM: pam_open_session(): Cannot make/remove an entry for the
> specified session
> syslogin_perform_logout: logout() returned an error
> 
> I suspect this is due to the restrictions placed on the proc file
> system mounted inside the container.

Yupp, probably.

> Could some of these restrictions be relaxed to make sshd work?
> Alternatively, it would be useful if it were possible to run both
> systemd and a shell inside the same container.

For that we'd have to know which ones that are ;-)

It might be worth editing the PAM config files for ssh and commenting
modules to figure out which ones are the offending ones.

> Any thoughts on the best way to proceed would be appreciated.

I think most of these errors are created by PAM modules, so commenting
them might help. That's a short-term fix, and a long-term fix I believe
is to make these failures non-fatal in the respective programs. So
please file bugs ;-).

Also, if you boot your host OS with selinux=0, things might work
better. SELinux is not really aware of the containers, and gets very
confused.

We try to ensure that the nspawn container cannot interfere with the
host system in any way. This is currently not perfect but goes
relatively far. For example we protect access to /proc/sys, /sys and
network interface configuration. Trying to change those from inside the
container will fail with EROFS, EACCES or EPERM. For testing, debugging,
and building these errors should generally not matter much however.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.