Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 334329 - net-analyzer/tcpdump[chroot] dropping privileges causes inconsistent dump file location to be used
Summary: net-analyzer/tcpdump[chroot] dropping privileges causes inconsistent dump fil...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major with 1 vote (vote)
Assignee: Mikle Kolyada (RETIRED)
URL:
Whiteboard:
Keywords: NeedPatch
: 358329 375325 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-08-24 18:38 UTC by Sébastien BAUDRU
Modified: 2020-11-14 17:39 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sébastien BAUDRU 2010-08-24 18:38:59 UTC
Bug verified on two gentoo systems :

uname -a
* Linux SERVER1 2.6.28.4-xxxx-std-ipv4-64 #2 SMP Wed Feb 18 16:34:21 UTC 2009 x86_64 Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz GenuineIntel GNU/Linux
* Linux SERVER2 2.6.35-gentoo-r1 #1 SMP Mon Aug 23 19:14:34 CEST 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux

Both of them have:
 - compiled in ~x86 / ~amd64
 - tcpdump 4.1.1 with uses "chroot ipv6 samba ssl -smi -suid -test"
 - libpcap 1.1.1-r1 with uses "ipv6 -bluetooth -libnl"

I try to use this simple command line :
 tcpdump -G 10 -w %H%S%M.pcap

It's supposed to run tcpdump and write datas in a file. The file change every 10 seconds (that's why it's a "strftime formated name"). I run the command, and for 10 seconds, everything's normal. After the first ten seconds, tcpdump may create a new file and store new datas in it. It doesn't.

We tryed on Debian X86 and AMD64. Both of them works as expected, with the same version of TCPcump and PCAP.

Reproducible: Always

Steps to Reproduce:
1. Launch two console in root, both in "/tmp"
2. On the first command line, type "tcpdump -G 10 %H%M%S.pcap"
3. On the second, type "watch -n 1 ls -l"
4. You cans ee on the second console that the first file grows, but ten second after, the size doesn't increase anymore. No other file will be created, although it's the normal behaviour of tcpdump.

Actual Results:  
One unique file (ex. 203140.pcap) that doesn't grow anymore.

Expected Results:  
Multiple file with the last number growing ten by ten 
ex. 203150.pcap, ten seconds after
ex. 203200.pcap, ten seconds after

...

You can try the "-Z" option, it's made to "drop privileges" of tcpdump. On Gentoo, tcpdump by default runs as user "tcpdump". I guessed it was only a permission problem (though I was in /tmp) so I tried "-Z root", so that tcpdump is run as root. No change.
Comment 1 Sébastien BAUDRU 2010-08-24 18:50:35 UTC
Ok, my bad. I found my way.

The problems comes from the "chroot" use flag. It tries to chroot tcpdump (the command) into the homedir of "tcpdump" (the user). BUT, on gentoo, the default HOMEDIR of tcpdump is... /dev/null.

Unfortunately, tcpdump won't fail with a message like "cannot chroot to dir". Maybe a message in "pkg_postintall()" to inform the user that the /var/lib/tcpdump will be used as chroot could help.

My bad, anyway.
Koreth
Comment 2 dacook 2011-03-08 16:16:29 UTC
This rather ugly behavior, to review:

  - run tcpdump -C or -G, -w /path/to/some/file.pcap
  - first file is placed in the requested path
  - subsequent files are silently dropped into /var/lib/tcpdump/

Especially when running extended or large captures, this behavior is wholly unacceptable.  Since USE=chroot is on by default, this absolutely needs documentation via ewarn or einfo, perhaps a manpage entry.  I understand the limitations of chroot and that it isn't easily fixable, but people operate under the assumption that files will generally go where they tell them.
Comment 3 Jeroen Roovers (RETIRED) gentoo-dev 2011-07-18 11:21:05 UTC
*** Bug 358329 has been marked as a duplicate of this bug. ***
Comment 4 Jeroen Roovers (RETIRED) gentoo-dev 2012-12-07 16:28:58 UTC
I have changed the USE flag description:

-  <flag name='chroot'>Enable chrooting when dropping privileges</flag>
+  <flag name='chroot'>Chroot into /var/lib/tcpdump when dropping privileges</flag>

ewarn/einfo should not be used to warn about features we set to be enabled by default, I think. We should rather discuss changing the default, or fix the -w behaviour.
Comment 5 grey dot 2012-12-12 22:48:53 UTC
> sudo tcpdump -w out.pcap
tcpdump: out.pcap: Permission denied

Please also remove '--with-user=tcpdump' if chroot flag is disabled. Otherwise tcpdump is unable to write files anywhere.
Comment 6 grey dot 2013-03-05 07:01:54 UTC
any update?
Comment 7 Yun Zheng Hu 2013-04-13 11:20:18 UTC
I ran into the same problem. A quick workaround was to redirect tcpdump to stdout/file: tcpdump -nr somepcap -w - 'tcp port 80' > /tmp/port80.pcap

I'm about to change our default USE flag for tcpdump to USE="-chroot" to fix this. But I guess I have to do some tests first by reading grey_dot's comment about the --with-user=tcpdump flag.
Comment 8 grey dot 2013-06-01 12:49:10 UTC
what the fuck? Guys, are you morons? Are you dense or something? The fix requires changing only one line in ebuild. JUST ONE FUCKING LINE. And you can't do it for the fucking three years. Geez, its fucking retarded.
Comment 9 Jeroen Roovers (RETIRED) gentoo-dev 2013-06-01 14:26:58 UTC
*** Bug 375325 has been marked as a duplicate of this bug. ***
Comment 10 Jeroen Roovers (RETIRED) gentoo-dev 2013-06-01 14:28:35 UTC
(In reply to grey dot from comment #8)
> what the fuck? Guys, are you morons? Are you dense or something? The fix
> requires changing only one line in ebuild. JUST ONE FUCKING LINE. And you
> can't do it for the fucking three years. Geez, its fucking retarded.

Thanks for the abuse. Got a patch?
Comment 11 consus 2013-06-01 15:54:58 UTC
--- /usr/portage/net-analyzer/tcpdump/tcpdump-4.4.0.ebuild	2013-05-30 00:31:23.000000000 +0400
+++ tcpdump-4.4.0.ebuild	2013-06-01 19:50:23.000000000 +0400
@@ -15,7 +15,7 @@
 LICENSE="BSD"
 SLOT="0"
 KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd ~x86-freebsd ~amd64-linux ~arm-linux ~x86-linux"
-IUSE="+chroot smi ssl ipv6 -samba suid test"
+IUSE="chroot smi ssl ipv6 -samba suid test"
 
 RDEPEND="
 	net-libs/libpcap
@@ -42,8 +42,12 @@
 		ewarn "CAUTION !!! CAUTION !!! CAUTION"
 		ewarn
 	fi
-	enewgroup tcpdump
-	enewuser tcpdump -1 -1 -1 tcpdump
+	if use chroot || use suid; then
+		enewgroup tcpdump
+	fi
+	if use chroot; then
+		enewuser tcpdump -1 -1 -1 tcpdump
+	fi
 }
 
 src_configure() {
@@ -53,13 +57,17 @@
 	replace-flags -O[3-9] -O2
 	filter-flags -finline-functions
 
+	if use chroot; then
+		chroot_opts='--with-user=tcpdump'
+	fi
+
 	econf \
-		--with-user=tcpdump \
 		$(use_with ssl crypto "${EPREFIX}/usr") \
 		$(use_with smi) \
 		$(use_enable ipv6) \
 		$(use_enable samba smb) \
-		$(use_with chroot chroot "${EPREFIX}/var/lib/tcpdump")
+		$(use_with chroot chroot "${EPREFIX}/var/lib/tcpdump") \
+		${chroot_opts}
 }
 
 src_test() {
Comment 12 consus 2013-06-01 15:56:03 UTC
Is this SO FUCKING HARD FOR YOU? Lend some brain.
Comment 13 grey dot 2013-06-01 16:42:04 UTC
(In reply to Jeroen Roovers from comment #10)
> (In reply to grey dot from comment #8)
> > what the fuck? Guys, are you morons? Are you dense or something? The fix
> > requires changing only one line in ebuild. JUST ONE FUCKING LINE. And you
> > can't do it for the fucking three years. Geez, its fucking retarded.
> 
> Thanks for the abuse. Got a patch?

This is not an abuse but merely a way to get your attention. Other ways seem to be ineffective.
Comment 14 Alec Warner (RETIRED) archtester gentoo-dev Security 2013-06-01 17:32:31 UTC
Calling the volunteers morons, idiots, cursing their work, and so forth, is not appropriate. I understand that you don't like this behavior (FWIW, I also hit it for the first time a couple of months ago and found it weird) but that is no excuse to be rude to people. Please do not do it again, otherwise you may attract a different sort of attention than you intended.

-A
Comment 15 consus 2013-06-01 17:36:40 UTC
(In reply to Alec Warner from comment #14)
> Calling the volunteers morons, idiots, cursing their work, and so forth, is
> not appropriate.

Volunteers can be morons too. This guy is a perfect example.
Comment 16 grey dot 2013-06-01 17:49:33 UTC
I will put my answer here, Jer.

>On Sat, 01 Jun 2013 12:49:10 +0000
>bugzilla-daemon@gentoo.org wrote:

>> DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
>> whose email is mentioned below. To comment on this bug, please visit:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=334329
>>
>> --- Comment #8 from grey dot <sickmind@lavabit.com> ---
>> what the fuck? Guys, are you morons? Are you dense or something? The
>> fix requires changing only one line in ebuild. JUST ONE FUCKING LINE.
>> And you can't do it for the fucking three years. Geez, its fucking
>> retarded.
>
>Please note that this kind of behaviour is unacceptable.
>
>
>     jer

I note that gentoo developers care more about some random guys' bad language than about bugs being open for years. I've posted several comments to this bug describing its behaviour and proposing a proper fix, but all I got is a goddamn USE-flag description changed. Almost every single bugreport I file is left without attention. But once I call everybody around names, and here you are. Sounds like a working plan, aint it?
Comment 17 grey dot 2013-06-01 18:03:58 UTC
(In reply to Alec Warner from comment #14)
> Calling the volunteers morons, idiots, cursing their work, and so forth, is
> not appropriate. I understand that you don't like this behavior (FWIW, I
> also hit it for the first time a couple of months ago and found it weird)
> but that is no excuse to be rude to people. Please do not do it again,
> otherwise you may attract a different sort of attention than you intended.
> 
> -A

Dear Alec,

Being rude worked perfectly so far. It took Mister Roovers less than two hours to point his attention to this bug after I called him a moron compared to two and a half years before that. Therefore I find this way almost 9000 times more effective (2 hours versus 2.5 years, huh?). If you can propose more effective way of communication with gentoo staff, I would really like to hear that.

Sincerely yours, Grey Dot.
Comment 18 Sergey Popov gentoo-dev 2013-06-01 18:31:13 UTC
(In reply to grey dot from comment #17)
> If you can propose
> more effective way of communication with gentoo staff, I would really like
> to hear that.

Actually, a far more proper way of hurrying things up is to ping maintainer on IRC in polite manner. Your way MAY work too, but such style of discussion is definetely the subject for User Relations(http://www.gentoo.org/proj/en/userrel/), so, please let's keep this bug clean from organizational stuff and concentrate on technical issues only
Comment 19 grey dot 2013-06-01 18:46:41 UTC
S(In reply to Sergey Popov from comment #18)
> (In reply to grey dot from comment #17)
> > If you can propose
> > more effective way of communication with gentoo staff, I would really like
> > to hear that.
> 
> Actually, a far more proper way of hurrying things up is to ping maintainer
> on IRC in polite manner. Your way MAY work too, but such style of discussion
> is definetely the subject for User
> Relations(http://www.gentoo.org/proj/en/userrel/), so, please let's keep
> this bug clean from organizational stuff and concentrate on technical issues
> only

Isn't that what bugzilla is for? I file a bug, bug wranglers assign it to specific maintainers, those dudes fix the bug, everyone is happy. Am I right?
Comment 20 Sergey Popov gentoo-dev 2013-06-01 20:13:14 UTC
(In reply to grey dot from comment #19)
> (In reply to Sergey Popov from comment #18)
> > (In reply to grey dot from comment #17)
> > > If you can propose
> > > more effective way of communication with gentoo staff, I would really like
> > > to hear that.
> > 
> > Actually, a far more proper way of hurrying things up is to ping maintainer
> > on IRC in polite manner. Your way MAY work too, but such style of discussion
> > is definetely the subject for User
> > Relations(http://www.gentoo.org/proj/en/userrel/), so, please let's keep
> > this bug clean from organizational stuff and concentrate on technical issues
> > only
> 
> Isn't that what bugzilla is for? I file a bug, bug wranglers assign it to
> specific maintainers, those dudes fix the bug, everyone is happy. Am I right?

Bugzilla is for tracking bugs, yes. But maintainers can not blindly apply suggested fixes - they should test them. Suggested fix for this bug was commited recently. If you want to discuss it or help testing it, channels #gentoo-netmon and #gentoo-dev-help are your choice...

And, i repeat, organizational questions about bug resolving workflows are definetely not fit to THIS bug, so, if you want to continue, let's move discussion about it to apropriate place(maillists or IRC)
Comment 21 consus 2013-06-01 20:47:37 UTC
> But maintainers can not blindly apply suggested fixes - they should test them.

Yeah, for almost three years. They're obviously in no hurry.
Comment 22 Sergey Popov gentoo-dev 2013-06-01 21:04:46 UTC
(In reply to consus from comment #21)
> > But maintainers can not blindly apply suggested fixes - they should test them.
> 
> Yeah, for almost three years. They're obviously in no hurry.

I do not understand what are you talking about here. Your fix was suggested at 2013-06-01 19:54:58 MSD

Do you think that if bug is reported, the proper fix is magically created in maintainer's head and then evil maintainer slows things down? :-)

Seriously, calm down. When you will be ready to talk(in constructive manner) - we will be happy to listen your suggestions.
Comment 23 consus 2013-06-01 21:10:21 UTC
> Do you think that if bug is reported, the proper fix is magically created in maintainer's head and then evil maintainer slows things down? :-)

No, but:

> Reported:	2010-08-24 18:38 UTC

And today is Jun 01 2013, but the way.

> Seriously, calm down. When you will be ready to talk(in constructive manner) - we will be happy to listen your suggestions.

I already gave you a patch. What suggestions do you need?
Comment 24 consus 2013-06-01 21:14:47 UTC
> I do not understand what are you talking about here. Your fix was suggested at 2013-06-01 19:54:58 MSD

*sighs*

>grey dot 2012-12-12 22:48:53 UTC

>> sudo tcpdump -w out.pcap
> tcpdump: out.pcap: Permission denied
> 
> Please also remove '--with-user=tcpdump' if chroot flag is disabled. Otherwise tcpdump is unable to write files anywhere.

Read the motherfucking thread before you motherfucking post ;)
Comment 25 Sergey Popov gentoo-dev 2013-06-01 21:27:54 UTC
(In reply to consus from comment #24)
> > I do not understand what are you talking about here. Your fix was suggested at 2013-06-01 19:54:58 MSD
> 
> *sighs*
> 
> >grey dot 2012-12-12 22:48:53 UTC
> 
> >> sudo tcpdump -w out.pcap
> > tcpdump: out.pcap: Permission denied
> > 
> > Please also remove '--with-user=tcpdump' if chroot flag is disabled. Otherwise tcpdump is unable to write files anywhere.
> 
> Read the motherfucking thread before you motherfucking post ;)

I am(again) strongly suggest you to change your attitude and calm down. I have read thread before posting, do not worry.
Comment 26 consus 2013-06-01 21:34:43 UTC
> I am(again) strongly suggest you to change your attitude and calm down. I
> have read thread before posting, do not worry.

Then I don't understand what are we discussing here.
Comment 27 Rick Farina (Zero_Chaos) gentoo-dev 2013-06-01 22:36:50 UTC
This is unacceptable behavior. I'm reassigning this bug to user relations until such time as people (read NO ONE) is being openly hostile on this bug.

Progress STOPPED.

Have a nice day.
Comment 28 Jorge Manuel B. S. Vicetto (RETIRED) Gentoo Infrastructure gentoo-dev 2013-06-01 22:51:52 UTC
(In reply to Alec Warner from comment #14)
> Calling the volunteers morons, idiots, cursing their work, and so forth, is
> not appropriate. I understand that you don't like this behavior (FWIW, I
> also hit it for the first time a couple of months ago and found it weird)
> but that is no excuse to be rude to people. Please do not do it again,
> otherwise you may attract a different sort of attention than you intended.
> 
> -A

Alec already gave an official warning as a User Relations team member.
I'm here to give a final warning: anyone exhibiting more abusive behaviour on this bug will get his/her bugzilla account locked until we (UserRel) are convinced the behaviour has changed.

Jorge
Comment 29 dacook 2013-06-02 02:18:20 UTC
It's unfortunate that it came to this to get this very simple bug fixed.  The patch provided only masks the behavior, but it's better than nothing.

Please.  Step beyond one user's obvious pathological frustration and see the issue here.  Stopping work because they're abusive doesn't help anything but your own ego.  Kick them out if you must, but this (among many bugs) is why Gentoo is slowly fading into my past.  I simply don't have the energy any more to maintain my own lateral repo with dozens of bugfixes just because my problems don't match the energy focus of the apparently small active set of devs.

No, I'm not interested in devship, that ship sailed long ago, for many reasons.
Comment 30 consus 2013-06-02 06:18:07 UTC
(In reply to dacook from comment #29)
> It's unfortunate that it came to this to get this very simple bug fixed. 
> The patch provided only masks the behavior, but it's better than nothing.

Could you be more specific, please? I tested this with chroot/suid/none flags enabled, everything seems to work fine for me.
Comment 31 consus 2013-06-02 06:19:54 UTC
> Progress STOPPED.

Please, eat shit and die.
Comment 32 grey dot 2013-06-02 12:08:55 UTC
I must apologize for my friend's behaviour, he's really easy to piss off. However it is your behaviour which is unacceptable. We have five gentoo developers in this thread and the bug still isn't fixed. I find this situation sadly ironic.
Comment 33 dacook 2013-06-02 13:09:22 UTC
In reply to conus from comment #30
> Could you be more specific, please? I tested this with chroot/suid/none flags 
> enabled, everything seems to work fine for me.

There's nothing wrong with your patch, it works to mask very edge behavior with extremely narrow usefulness.  I guess I would rather see something come from upstream to make this set of "features" less onerous as well, but that's a blue-sky kind of thing.
Comment 34 consus 2013-06-02 13:36:36 UTC
>Jeroen Roovers 2013-06-02 13:22:20 UTC
>Keywords: PATCH → NeedPatch

Sounds like a plan! Someone, please write a patch. Oh, wait... :D
Comment 35 consus 2013-06-02 13:49:44 UTC
(In reply to dacook from comment #33)
> I guess I would rather see something come
> from upstream to make this set of "features" less onerous as well, but
> that's a blue-sky kind of thing.

As far as can tell there is nothing wrong with upstream:
 
--with-user=USERNAME    drop privileges by default to USERNAME

So everything works just as planned -- tcpdump drops priveleges to user 'tcpdump', and after this you obviously cannot write to your home dir.
Comment 36 Jorge Manuel B. S. Vicetto (RETIRED) Gentoo Infrastructure gentoo-dev 2013-06-02 13:53:35 UTC
(In reply to consus from comment #31)
> > Progress STOPPED.
> 
> Please, eat shit and die.

Account locked per my warning.
Comment 37 Sergey Popov gentoo-dev 2013-06-03 06:19:24 UTC
(In reply to consus from comment #34)
> >Jeroen Roovers 2013-06-02 13:22:20 UTC
> >Keywords: PATCH → NeedPatch
> 
> Sounds like a plan! Someone, please write a patch. Oh, wait... :D

Your patch does not solve this problem, thus - keywords was changed to NeedPatch

(In reply to grey dot from comment #32)
> However it is your behaviour which is unacceptable. We have five gentoo
> developers in this thread and the bug still isn't fixed. I find this
> situation sadly ironic.

1) Gentoo developer is not "jack of all trades". Gazillion of skilled Ruby/Perl/Python/Ocaml/whatever guys can stuck with one heavy C++ package. That's why we have teams.
2) Not all of us here are part of netmon team(well, actually i am)
3) Not all of us are familiar with this package

I have looked at suggested materials and it seems that we are stuck here, cause they are workarounds. No doubt, they will work in one particular case and possibly fit for some users, but the whole issue will not be solved with them.

Possibly Jeroen knows better, cause he made a lot of work for tcpdump ebuilds
Comment 38 Denis Ovsienko 2020-08-24 11:33:08 UTC
I am one of tcpdump maintainers and I was pointed to this bug report today. If this bug still reproduces on the current master branch of tcpdump, please file it with very exact steps to reproduce (the developers are not Gentoo users) at [1]. 

Though the upstream bug tracker is very short on developer resource too, a proper eventual bugfix may be more likely this way. Thank you.

1: https://github.com/the-tcpdump-group/tcpdump/issues
Comment 39 Andrey 2020-09-13 03:41:26 UTC
Seems to work fine for me these days.

Versions and USE flags are as follows:
net-analyzer/tcpdump-4.9.3::gentoo  USE="drop-root -libressl -samba -smi ssl -suid -test"
net-libs/libpcap-1.9.1::gentoo  USE="-bluetooth -dbus netlink -static-libs -usb"

Running as root:
$ cd /tmp
$ tcpdump -G 10 -w 'qqq_%H%S%M.pcap' -W 3 -n -p -v -i eth0
dropped privs to tcpdump
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
Maximum file limit reached: 3
465 packets captured
466 packets received by filter
0 packets dropped by kernel

$ ls -l qqq_*
-rw-r--r-- 1 tcpdump tcpdump 253385 Sep 13 06:32 qqq_060132.pcap
-rw-r--r-- 1 tcpdump tcpdump  74434 Sep 13 06:32 qqq_061232.pcap
-rw-r--r-- 1 tcpdump tcpdump  21108 Sep 13 06:32 qqq_065131.pcap


This even works when writing to /root
$ tcpdump -G 10 -w '/root/qqq_%H%S%M.pcap' -W 3 -n -p -v -i eth0
dropped privs to tcpdump
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
Maximum file limit reached: 3
227 packets captured
531 packets received by filter
0 packets dropped by kernel

$  ls -l /root/qqq_*
-rw-r--r-- 1 tcpdump tcpdump 25139 Sep 13 06:34 /root/qqq_060934.pcap
-rw-r--r-- 1 tcpdump tcpdump 91059 Sep 13 06:34 /root/qqq_062534.pcap
-rw-r--r-- 1 tcpdump tcpdump 10818 Sep 13 06:34 /root/qqq_065933.pcap


For reference, current stable ebuild does the following:
src_configure() {
    if use drop-root; then
        append-cppflags -DHAVE_CAP_NG_H
        export LIBS=$( $(tc-getPKG_CONFIG) --libs libcap-ng )
    fi

    econf \
        $(use_enable samba smb) \
        $(use_with drop-root chroot '') \
        $(use_with smi) \
        $(use_with ssl crypto "${ESYSROOT}/usr") \
        $(usex drop-root "--with-user=tcpdump" "")
}

which is equivalent to
./configure --with-chroot='' --with-user=tcpdump ...
Comment 40 Andrey 2020-09-13 03:58:05 UTC
> which is equivalent to
> ./configure --with-chroot='' --with-user=tcpdump ...

It seems to be this way since tcpdump-4.4.0-r1, which was committed in 2013 per
https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/net-analyzer/tcpdump?id=5753f0e8c6d6f948fb96674ea04dd17b7eb9e1f9
which mentions that use of libcap-ng could have helped here.
--with-chroot='' vs --with-chroot='/var/lib/tcpdump' is another difference between 4.4.0 and 4.4.0-r1.
Comment 41 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2020-11-14 17:39:48 UTC
Hmm yeah, I can not reproduce this anymore as well