Hi -
> Having recently looked into the requirements of supporting the Linux
> kernel container technologies, I propose here an extension to the
> way in which pmcd operates. [...]
Looks good. It sounds like a meta-pmcd kind of like inetd, launching
pmcds on demand, nailing some of them into containers if desired. It
could even defer the startup of the primary pmcd/pmdas until a client
arrives. It does not preclude people installing vanilla PMCD's into
containers.
Do you see the meta-pmcd functioning as a communication relay for the
inferior pmcds (since a host-side client cannot in general talk to /
address the networks of the containers). Or perhaps passing a
per-client file descriptor to the appropriate sub-pmcd (in which case,
take care of NSS / sockname / etc. issues). In any case the
meta-sub-pmcd protocol would be a bit tricky.
The meta-pmcd's authentication credentials need bear no resemblance to
the credentials valid within a random container. So if the meta-pmcd
uses the credentials, it should not pass them to sub-pmcds (esp. in
plaintext). Thus, authenticated per-container access would not be
possible without more extensions. Or maybe leave this problem up to a
dedicated setuid pmcd-authenticator widget?
Use of the meta-pmcd to restart PMDAs on demand could be helpful, if
one can work out the details of scoping (are PMDAs of containerized
sub-pmcds included?) and implementation (creation & passing of the
pmcd<->pmda pipes, notification of pmcd, killing an orphaned pmda,
etc.). Or maybe leave this problem up to a new dedicated setuid
pmda-restarter widget?
- FChE
|