why strace dumpcap fail?

[leveryd]

[test@instance-h9w7mlyv ~]$ dumpcap
Capturing on 'eth0'
File: /var/tmp/wireshark_eth0_20220822114539_BK9d9l.pcapng
Packets captured: 12
Packets received/dropped on interface 'eth0': 12/0 (pcap:0/dumpcap:0/flushed:0/ps_ifdrop:0) (100.0%)
[test@instance-h9w7mlyv ~]$

[test@instance-h9w7mlyv ~]$ strace dumpcap
...
socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) = -1 EPERM (Operation not permitted)
stat(0x55fb3851ea20, 0x7ffe66fa24f0)    = -1 ENOENT (No such file or directory)
write(2, 0x55fb372c18e5, 9dumpcap: )             = 9
write(2, 0x7ffe66f9fd10, 117The capture session could not be initiated on interface 'eth0' (You don't have permission to capture on that device).)           = 117
write(2, 0x7f4107b52683, 1
)             = 1
write(2, 0x7ffe66f9fd40, 466Please check to make sure you have sufficient permissions.

On Debian and Debian derivatives such as Ubuntu, if you have installed Wireshark from a package, try running

    sudo dpkg-reconfigure wireshark-common

selecting "<Yes>" in response to the question

    Should non-superusers be able to capture packets?

adding yourself to the "wireshark" group by running

    sudo usermod -a -G wireshark {your username}

and then logging out and logging back in again.)           = 466
write(2, 0x7f4107b52683, 1
)             = 1
exit_group(1)                           = ?

non-root user run dumpcap looks good, but run strace dumpcap looks bad. WHY?

dumpcap can be installed by yum install wireshark.

[leveryd]

run strace ls、strace cat looks good too.

[test@instance-h9w7mlyv tmp]$ strace ls
...
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x2), ...}) = 0
write(1, "1  1234  1.c  1.php  2.c  a  a.c"..., 1931  1234  1.c  1.php  2.c  a  a.c  a.out  b  b.c  c.c  e.c  f.c	lcap.c	Makefile  q.c  redis-server  systemd-private-cadce8b6014e4053aa540e5af070d6f9-chronyd.service-IcLArj  x.conf  x.php  y.php
) = 193
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

[esyr]

On Thu, Aug 25, 2022 at 10:52 AM leveryd ***@***.***> wrote: $ ***@***.*** ~]$ strace dumpcap ... socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) = -1 EPERM (Operation not permitted) non-root user run dumpcap looks good, but run strace dumpcap looks bad. WHY?

As packet(7) says (and the code in net/packet/af_packet.c:packet_create() corroborates), "In order to create a packet socket, a process must have the CAP_NET_RAW capability". This capability is obtained by the dumpcap binary by the means of file capabilities, as "getcap `which dumpcap`" suggests ("/usr/bin/dumpcap cap_net_admin,cap_net_raw=eip"). Since dumpcap is exec'ed by the strace's process (that is forked and already being attached to the tracer one), the additional file permissions are ignored, as documented in capabilities(7): "during the capability transitions described above, file capabilities may be ignored (treated as empty) for the same reasons that the set-user-ID and set-group-ID bits are ignored", execve(2): "[t]he aforementioned transformations of the effective IDs are not performed [...] if any of the following is true: [...] the calling process is being ptraced. [...] The capabilities of the program file (see capabilities(7)) are also ignored if any of the above are true", and corroborated by the code in fs/exec.c:check_unsafe_exec() and security/commoncap.c:cap_bprm_creds_from_file(). It is only natural to expect that one cannot simply elevate privileges for a ptrace'ed process, after all. As capabilities(7) also notes, "[w]hen attempting to strace(1) binaries that have capabilities (or set-user-ID-root binaries), you may find the -u <username> option useful".

…

-- Eugene Syromyatnikov ***@***.*** ***@***.***{ru|org}