I am going by the advice of paper " The Murky Issue of Changing Process Identity: Revising “Setuid Demystified” "
On page 7, it says: Specifically, all OSes that support getresuid (see Figure 3) also support setresuid and setresgid. These offer the clearest and most consistent semantics, and can be used by privileged and non-privileged processes alike. According to the paper, setuid() may or may not change saved uid, it is OS dependent and may only change effective uid in cause current uid is not zero. Also according to the same paper in Figure 3, getresuid() is supported by Linux, HPUX, FreeBSD and OpenBSD, it would be nice to let those OS use this API. For NetBSD, we can resolve this by emulating the getresuid() call. Make sense? On Sun, Oct 18, 2015 at 11:48 PM, Takashi Yamamoto <yamam...@midokura.com> wrote: > hi, > > On Mon, Oct 19, 2015 at 3:14 PM, Andy Zhou <az...@nicira.com> wrote: >> On Sun, Oct 18, 2015 at 9:28 PM, YAMAMOTO Takashi <yamam...@midokura.com> >> wrote: >>> NetBSD doesn't have [gs]etres[ug]id. >>> >>> Signed-off-by: YAMAMOTO Takashi <yamam...@midokura.com> >>> --- >>> lib/daemon-unix.c | 40 ++++++++++++++++++---------------------- >>> 1 file changed, 18 insertions(+), 22 deletions(-) >>> >> Thanks for testing on NetBSD. >> >> I am concerned that on platforms supports saved uid, Would this patch >> leave that value not changed, thus open up a security risk? >> >> How about we add a stub version of [gs]etres[ug]id for the NetBSD >> platform that can safely ignore the saved uid/ gid for that platform? > > NetBSD has saved uid/gid. > saved ids are expected to be changed by set[ug]id. > http://pubs.opengroup.org/onlinepubs/9699919799/functions/setuid.html > http://man.netbsd.org/HEAD/usr/share/man/html2/setuid.html > > i'm not sure what security risks you are concerning about. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
