On Fri, Sep 18, 2015 at 12:40 PM, Ben Pfaff <b...@nicira.com> wrote: > On Mon, Sep 14, 2015 at 03:54:07PM -0700, Andy Zhou wrote: >> This patch adds an argument to daemon_become_new_user() API for the >> caller specify whether the capability of accessing the kernel datapath >> is needed. On Linux, daemons access the kernel datapath need to >> retain some root privileges, such as CAP_NET_ADMIN. >> >> Current implementation (of retaining CAP_NET_ADMIN) requires libcap-ng. >> This implementation only covers the Linux. >> Other Unix platforms currently do not support kernel based datapath. >> (but supports --user options for all daemons.) >> On Windows, daemon_become_new_user() is a stub function that does >> nothing. >> >> Signed-off-by: Andy Zhou <az...@nicira.com> > > The manpage for capng_have_capabilities() says: > > The capabilities sets must be previ ously setup with calls to > capng_get_caps_process, capng_get_caps_fd, or in some other way > setup. > > but I don't see anything doing that before the call.
I missed this. It should have been called. > > The capng_change_id() call seems like it should include > CAPNG_INIT_SUPP_GRP so that groups from the new uid get included, for > consistency with the non-capng based version. Good catch. > > With this patch, in the case where libcap-ng is available and > capng_have_capabilities() returns false, daemon_become_new_user() does > nothing at all. That means, as far as I can tell, that it silently > fails in that case to change uid and gid to what was requested. > It should fail. I will fix it. > I'm concerned that there are, after this patch, two different ways to > switch to a new uid and gid on the same system, one of them used by some > daemons and the other by other daemons, and that in some cases the > method used by some daemons just won't be supported and will abort. > That kind of complexity is going to cause confusion and in a security > context that means it will cause security holes. What can we do to > reduce the complexity? My suggestion is that we should always use > libcap-ng in all cases on Linux. Then it's less nuanced and easier to > explain and I think that it's more likely to be used correctly in > practice. Sure, make sense. I will use libcap-ng on Linux, setresuid() for other Unix platform Windows platform should not accept the --user option, at least not until it is supported on that platform. > > Thanks, > > Ben. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
