[sudo-workers] Is there a way to avoid get_net_ifs() when the information won't be used?

[Rick Jones]

On 01/22/2014 07:49 PM, Todd C. Miller wrote:
> Can you try the following diff and see if that fixes the slowdown?

Sure.

While the patch did apply with fuzz to the 1.8.3pl1+ubuntu sources I'd 
been using via apt-get source, it didn't compile - didn't like "false" 
and then didn't like debug_return_bool(), so I went ahead and grabbed 
the latest tar.gz from http://www.sudo.ws/sudo/download.html

Here are a couple timings with that  version pre-patch just for the sake 
of pedantry and crossed i's and dotted t's :)

rjones2 at qu-stbaz1-perf0002:~$ time ./sudo-1.8.9p4 sleep 1

real	0m1.314s
user	0m0.036s
sys	0m0.276s
rjones2 at qu-stbaz1-perf0002:~$ time ./sudo-1.8.9p4 sleep 1

real	0m1.319s
user	0m0.032s
sys	0m0.284s
rjones2 at qu-stbaz1-perf0002:~$ time ./sudo-1.8.9p4 sleep 1

real	0m1.319s
user	0m0.040s
sys	0m0.280s

I then applied the patch:

raj at tardy:/tmp/sudo-1.8.9p4$ patch -p 1 < /tmp/sudo.patch
(Stripping trailing CRs from patch.)
patching file plugins/sudoers/match_addr.c

and it built fine.  I put the resulting sudoers.so into place (as a new 
sudo binary was not built I didn't bother bringing that over to my test 
system) and ran again and the run times are virtually unchanged:

rjones2 at qu-stbaz1-perf0002:~$ time ./sudo-1.8.9p4 sleep 1

real	0m1.324s
user	0m0.036s
sys	0m0.284s
rjones2 at qu-stbaz1-perf0002:~$ time ./sudo-1.8.9p4 sleep 1

real	0m1.320s
user	0m0.036s
sys	0m0.280s
rjones2 at qu-stbaz1-perf0002:~$ time ./sudo-1.8.9p4 sleep 1

real	0m1.330s
user	0m0.040s
sys	0m0.292s

 From what I can ascertain, the problem is in making the get_net_ifs() 
call in the main code, which then makes the get_ifaddrs() call.  When 
there are a large number of interfaces, that is going to consume lots 
and lots of time.  Here is a snippet of an strace of that from the 
original 1.8.3+ubuntu version:

sudo strace -f -v -tttT -o /tmp/sudo_time.strace sudo sleep 1
...
63520 1390345686.461245 sendto(3, 
"\24\0\0\0\22\0\1\3\326\375\336R\0\0\0\0\0\0\0\0", 20, 0, 
{sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 <0.205799>
63520 1390345686.667080 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, 
pid=0, groups=00000000}, msg_iov(1)=[{"\374\3\0\0\20\0\2\0\326\375\336R 
\370\0\0\0\0\1\0\0'\0\0C\24\1\0\0\0\0\0"..., 4096}], msg_controllen=0, 
msg_flags=0}, 0) = 3108 <0.000163>
63520 1390345686.667285 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, 
pid=0, groups=00000000}, msg_iov(1)=[{"\374\3\0\0\20\0\2\0\326\375\336R 
\370\0\0\0\0\1\0\0\"\0\0C\24\1\0\0\0\0\0"..., 4096}], msg_controllen=0, 
msg_flags=0}, 0) = 3108 <0.000151>
...
63520 1390345687.641022 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, 
pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0\327\375\336R 
\370\0\0\n@\200\375\374\t\0\0\24\0\1\0\376\200\0\0"..., 4096}], 
msg_controllen=0, msg_flags=0}, 0) = 3008 <0.000066>
63520 1390345687.641112 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, 
pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\327\375\336R 
\370\0\0\0\0\0\0\374\t\0\0\24\0\1\0\376\200\0\0"..., 4096}], 
msg_controllen=0, msg_flags=0}, 0) = 20 <0.000006>

In the conditions under which that was gathered, there were 1600 of 
those recvmsg() calls to get the list of interfaces.

rick