Colin Walters <walters@xxxxxxxxxx> wrote:
> Why not drop the upcall model in favor of having userspace monitor events
> via a (more efficient) protocol and react to them on its own?
(1) That's not necessarily more efficient. You now have the overhead of a
permanently running userspace daemon in every relevant namespace
combination.
(2) You then have to work out how to route to the appropriate daemon.
> It's just generally more flexible
Actually, it's less flexible. You can't easily get at the caller's
namespaces.
> and avoids all of those issues like replicating the seccomp configuration,
> etc.
So does my container implementation.
> Something like inotify/signalfd could be a precedent around having a read()/poll()able
> fd. /proc/keys-requests ?
>
> Then if you create a new user namespace, and open /proc/keys-requests, the
> kernel will always write to that instead of calling /sbin/request-key.
That's not good enough. You're basically making it one daemon per user
namespace and ignoring all the other namespaces.
[Also note that the kernel would have to paste a temporary authorisation key
into the daemon's session keyring for each key that requires instantiation].
David
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
