hi, On Tue, Oct 20, 2015 at 7:14 AM, Andy Zhou <az...@nicira.com> wrote: > 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?
well, this fallback code is currently for FreeBSD and NetBSD, for which the semantics are consistent, right? > > > > 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
