Configuration-wise, if you don't configure user/group (via,
--enable-user and --enable-group) you get user=group=quagga by default.
If you do configure them then you get what you configure. I have tried
--disable-user and --disable-group and it was equivalent to setting the
user/group to root. Would it make sense to make --disable-user and
--disable-group unset QUAGGA_USER and QUAGGA_GROUP in the configuration
to trigger the new behavior (one of what you described below)? As it
stands this is the only change needed to make things work, although I
like your third suggestion so I will try and get that to work as well.
Regards,
Jafar
On 7/27/2016 7:36 AM, Paul Jakma wrote:
On Fri, 22 Jul 2016, Jafar Al-Gharaibeh wrote:
If do create a patch to drop this as a config/compile for corner
cases like the situation I have, would it be useful to upstream?
Sure.
I was going to write that you can just add a 'null' privs module, but
seems I already allowed for that in the existing code. If the zprivs
struct passed to zprivs_init has null group, user and caps, then it
should just install a null privilege handler.
So, just arrange for that to happen. Or else, make it so zprivs_init
(NULL) installs the null handler (rather than exit) and arrange for
that somehow.
Or perhaps better, as it'd be nice to still support dropping
capabilities generally, modify it so zprivs_init can be told to not do
any user/uid lookups but still try do its caps stuff.
regards,
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
