On Tue, 2017-05-23 at 10:54 -0400, Colin Walters wrote: > On Tue, May 23, 2017, at 10:30 AM, Djalal Harouni wrote: > > > > Maybe it depends on the cases, a general approach can be too difficult > > to handle especially from the security point. Maybe it is better to > > identify what operations need what context, and a userspace > > service/proxy can act using kthreadd with the right context... at > > least the shift to this model has been done for years now in the > > mobile industry. > > 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? > It's just generally more flexible and avoids all of those issues like > replicating the seccomp configuration, etc. > > 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. Case in point: nfsdcltrack was originally nfsdcld, a long running daemon that used rpc_pipefs to talk to the kernel. That meant that you had to make sure it gets enabled by systemd (or sysvinit, etc). If it dies, then you also want to ensure that it gets restarted lest the kernel server hang, etc... It was pretty universally hated, as it was just one more daemon that you needed to run to work a proper nfs server. So, I was encouraged to switch it to a call_usermodehelper upcall and since then it has just worked, as long as the binary is installed. It's quite easy to say: "You're doing it wrong. You just need to run all of these services as long-running daemons." But, that ignores the fact that handling long-running daemons for infrequently used upcalls is actually quite painful to manage in practice. -- Jeff Layton <jlayton@xxxxxxxxxx>
