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.
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.
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.
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.
Thanks,
Ben.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
