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.
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
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.
*** Bug 358329 has been marked as a duplicate of this bug. ***
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.
> 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.
any update?
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.
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.
*** Bug 375325 has been marked as a duplicate of this bug. ***
(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?
--- /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() {
Is this SO FUCKING HARD FOR YOU? Lend some brain.
(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.
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
(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.
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?
(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.
(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
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?
(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)
> But maintainers can not blindly apply suggested fixes - they should test them. Yeah, for almost three years. They're obviously in no hurry.
(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.
> 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?
> 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 ;)
(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.
> 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.
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.
(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
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.
(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.
> Progress STOPPED. Please, eat shit and die.
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.
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.
>Jeroen Roovers 2013-06-02 13:22:20 UTC >Keywords: PATCH → NeedPatch Sounds like a plan! Someone, please write a patch. Oh, wait... :D
(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.
(In reply to consus from comment #31) > > Progress STOPPED. > > Please, eat shit and die. Account locked per my warning.
(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
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
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 ...
> 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.
Hmm yeah, I can not reproduce this anymore as well