Looks like culprit is libnss_resonve.so.

First of all, to reproduce, I have to use hostname like google.com. If I
give traceroute an IP address, there are no setsockopt calls that needs
net_admin cap.

Here's gdb log, breakpointed on setsockopt, dumped registers (you can
see rdx set to "33" so that's one of SO_RCVBUFFORCE/SO_SNDBUFFORCE), and
backtrace, that leads to /lib/x86_64-linux-gnu/libnss_resolve.so.2:

Breakpoint 1 (setsockopt) pending.
Starting program: /usr/sbin/traceroute -T google.com
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, setsockopt () at ../sysdeps/unix/syscall-template.S:84
84      ../sysdeps/unix/syscall-template.S: No such file or directory.
rax            0x34000  212992
rbx            0x55ad9953abe0   94204090100704
rcx            0x7ffc27aac6d0   140720973989584
rdx            0x21     33
rsi            0x1      1
rdi            0x3      3
rbp            0x7ffc27aac6d0   0x7ffc27aac6d0
rsp            0x7ffc27aac6c8   0x7ffc27aac6c8
r8             0x4      4
r9             0x0      0
r10            0x7ffc27aac6d0   140720973989584
r11            0x202    514
r12            0x3      3
r13            0x7ffc27aac6d4   140720973989588
r14            0x7ffc27aac760   140720973989728
r15            0x55ad9953abe0   94204090100704
rip            0x7f057a78a320   0x7f057a78a320 <setsockopt>
eflags         0x293    [ CF AF SF IF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
#0  setsockopt () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f057af2cd43 in ?? () from /lib/x86_64-linux-gnu/libnss_resolve.so.2
#2  0x00007f057af1ccd5 in ?? () from /lib/x86_64-linux-gnu/libnss_resolve.so.2
#3  0x00007f057af46f02 in ?? () from /lib/x86_64-linux-gnu/libnss_resolve.so.2
#4  0x00007f057af2287d in _nss_resolve_gethostbyname4_r () from 
/lib/x86_64-linux-gnu/libnss_resolve.so.2
#5  0x00007f057a76e16f in gaih_inet (name=name@entry=0x7ffc27aae76e 
"google.com", service=<optimized out>, req=req@entry=0x7ffc27aad400, 
pai=pai@entry=0x7ffc27aacf28, naddrs=naddrs@entry=0x7ffc27aacf24, 
    tmpbuf=tmpbuf@entry=0x7ffc27aacf90) at ../sysdeps/posix/getaddrinfo.c:848
#6  0x00007f057a770448 in __GI_getaddrinfo (name=<optimized out>, 
service=<optimized out>, hints=0x7ffc27aad400, pai=0x7ffc27aad3f8) at 
../sysdeps/posix/getaddrinfo.c:2391
#7  0x000055ad9791e326 in ?? ()
#8  0x000055ad9791e4b3 in ?? ()
#9  0x000055ad97921cae in ?? ()
#10 0x000055ad9791a7d1 in ?? ()
#11 0x00007f057a6a13f1 in __libc_start_main (main=0x55ad9791a700, argc=3, 
argv=0x7ffc27aad888, init=<optimized out>, fini=<optimized out>, 
rtld_fini=<optimized out>, stack_end=0x7ffc27aad878)
    at ../csu/libc-start.c:291
#12 0x000055ad9791b3fa in ?? ()


** Also affects: systemd (Ubuntu)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1703649

Title:
  Traceroute needs net_admin capability for unknown reason

Status in systemd package in Ubuntu:
  New
Status in traceroute package in Ubuntu:
  New

Bug description:
  With help of AppArmor on 17.04 and 17.10 I've discovered that
  traceroute needs net_admin capabilities.

  My plan is to update [0] AppArmor profile to fix various DENIED
  messages in syslog/audit for traceroute, though I am not sure about
  allowing, or denying, net_admin capability.

  Looks like traceroute tries to set SO_RCVBUFFORCE and SO_SNDBUFFORCE:

  setsockopt(4, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation 
not permitted)
  setsockopt(4, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
  setsockopt(4, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation 
not permitted)
  setsockopt(4, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
  setsockopt(4, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation 
not permitted)
  setsockopt(4, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
  setsockopt(4, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation 
not permitted)
  setsockopt(4, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
  setsockopt(4, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation 
not permitted)
  setsockopt(4, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
  setsockopt(4, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation 
not permitted)
  setsockopt(4, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
  setsockopt(4, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation 
not permitted)
  setsockopt(4, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
  setsockopt(4, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation 
not permitted)

  What is interesting, that traceroute developer does not recall
  changing these values [1]. On Debian Sid and OpenSuse Tumbleweed this
  issue does not reproduce either.

  Could it be some Ubuntu-specific patch in the works? It seems that
  traceroute works OK without net_admin...

  Thanks!

  [0] 
https://code.launchpad.net/~talkless/apparmor/fix_traceroute_tcp/+merge/326260
  [1] https://sourceforge.net/p/traceroute/mailman/message/35927818/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1703649/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to