Aaron Conole writes:
> Ben Pfaff writes:
>
>> Well, is it ever useful to be able to drop unneeded capabilities while
>> retaining the same uid/gid? It certainly sounds like a reasonable thing
>> to want to do. I'm reluctant to apply this without at least
Does it make sense to drop priviledges from root:root? If yes, how can it
be decide which are the unneeded capabilities?
To fix UIO support, the minimal change required would be to keep
CAP_SYS_ADMIN when --user=root:root. Is this strategy preferable?
On Fri, Feb 2, 2018 at 9:22 PM, Ben Pfaff
Well, is it ever useful to be able to drop unneeded capabilities while
retaining the same uid/gid? It certainly sounds like a reasonable thing
to want to do. I'm reluctant to apply this without at least considering
that possibility.
On Fri, Feb 02, 2018 at 12:30:50AM -0200, Marcos Felipe
Is there any reason why they couldn't be the same?
One reason in favor is that the option for running ovs as a non-root user
can't be deactivated correctly by the means in the documentation [1]. It
states that setting OVS_USER_ID to 'root:root', or commenting the variable
out in
OK, I understand now that the goal is that passing "--user $UID" should
not call setuid() or setgid(). In that case, though, why pass the
--user option at all? I believe that, with this patch, "--user $UID"
and "" yield equivalent behavior.
Thanks,
Ben.
On Thu, Feb 01, 2018 at 09:34:12PM
On Thu, Feb 01, 2018 at 03:42:03PM -0200, Marcos Felipe Schwarz wrote:
> Since 2.8.0 OVS runs as non-root user on rhel distros, but the current
> implementation breaks the ability to run as root with DPDK and as a
> consequence there is no way possible to use UIO drivers on kernel 4.0 and
> newer
Since 2.8.0 OVS runs as non-root user on rhel distros, but the current
implementation breaks the ability to run as root with DPDK and as a
consequence there is no way possible to use UIO drivers on kernel 4.0 and
newer [1, 2].
[1] http://dpdk.org/browse/dpdk/commit/?id=cdc242f260e766