Description of problem: When I try to use tcpdump with -z gzip parameter, when it's time to logrotate tcpdump fails on: gzip: out.pcap.gz: Permission denied Version-Release number of selected component (if applicable): $ rpm -qa tcpdump tcpdump-4.9.3-1.fc31.x86_64 $ rpm -qa gzip gzip-1.10-1.fc31.x86_64 $ cat /etc/fedora-release Fedora release 31 (Thirty One) How reproducible: every time Steps to Reproduce: 1. log as root 2. run tcpdump -i any -s0 'tcp port 22' -G 10 -z gzip -w out.pcap # G 10 means logrotation to gzip is going to be performed every 10 seconds 3. create some traffic on ssh, for example "ssh github.com -l git" 4. tcpdump will report: gzip: out.pcap.gz: Permission denied Additional info: $ ls -laZ out.pcap -rw-rw-rw-. 1 tcpdump tcpdump unconfined_u:object_r:mnt_t:s0 4096 Jul 15 08:16 out.pcap
Hi Andrej, I recently found out that this is actually caused by our own patch. I am planning to remove it. The ideal scenario is that the 'permission denied' error is produced right at the beginning and not after the rotation period.
(In reply to Michal Ruprich 🐧 from comment #1) > Hi Andrej, > > I recently found out that this is actually caused by our own patch. I am > planning to remove it. The ideal scenario is that the 'permission denied' > error is produced right at the beginning and not after the rotation period. Hi Michal, Feel free to send me engineering build which I can test so you guys don't have to :)
Thanks, here is a scratch build in Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=47302919 I just removed our patch.
Hi Michal I tested your build and here is what I've got. Original problem was that when I tried to logrotate pcaps using parameter -z gzip, tcpdump wasn't able to create gzip file and failed when it was time to logrotate. When I did same thing in this build tcpdump notified me about not having rights for file and failed immediatelly: --- burlak@dellicious ~/s/tcpdump $ ls -la total 8 drwxrwxr-x. 2 burlak burlak 4096 Jul 19 23:55 . drwxrwxr-x. 15 burlak burlak 4096 Jul 19 23:55 .. burlak@dellicious ~/s/tcpdump $ sudo id uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 burlak@dellicious ~/s/tcpdump $ sudo tcpdump -i any -s0 'tcp port 22' -G 10 -z gzip -w out.pcap dropped privs to tcpdump tcpdump: out.pcap: Permission denied --- So I tried to create file out.pcap which is owned by user tcpdump: --- burlak@dellicious ~/s/tcpdump $ sudo chown tcpdump:tcpdump out.pcap burlak@dellicious ~/s/tcpdump $ sudo tcpdump -i any -s0 'tcp port 22' -G 10 -z gzip -w out.pcap dropped privs to tcpdump tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes gzip: out.pcap.gz: Permission denied gzip: out.pcap.gz: Permission denied --- And it was behaving same as previous version. So I tried to do the same for whole directory: --- burlak@dellicious ~/s/tcpdump $ mkdir rights-tcpdump burlak@dellicious ~/s/tcpdump $ sudo chown tcpdump:tcpdump ./rights-tcpdump burlak@dellicious ~/s/tcpdump $ cd rights-tcpdump/ burlak@dellicious ~/s/t/rights-tcpdump $ burlak@dellicious ~/s/t/rights-tcpdump $ sudo tcpdump -i any -s0 'tcp port 22' -G 10 -z gzip -w out.pcap dropped privs to tcpdump tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes ^C257 packets captured 267 packets received by filter 0 packets dropped by kernel burlak@dellicious ~/s/t/rights-tcpdump $ ls out.pcap.gz --- And as you can see, with saving dump in to the directory owned by tcpdump it worked. My issue is that without using -z gzip param, tcpdump is able to create file under user root or another user with sufficient privileges but when is -z gzip param used tcpdump drops privileges sooner than probably should and it's no longer able to do that.
Hi Andrej, but this is expected. tcpdump always drops privileges to 'tcpdump' before capturing. It even says 'dropped privs to tcpdump'. The point here is that it should notify you before you start, not after some period when it is supposed to rotate the dump files. This is done by default by tcpdump because capturing as root might be dangerous in some cases. What you did - creating a dir with tcpdump owner - that is exactly how you should do it before capturing. If by any chance you need root to be the one doing the capture than you can run tcpdump as root and use the '-Z root' option. You will see this message before the capturing: 'dropped privs to root'. Now you can create files anywhere. Anyway, I will remove the patch so that the error is visible right away at the beginning. Hope this helps. Regards, Michal
Hi Michal, I get why it's happening, but it's still happening in case you'll create out.pcap with tcpdump rights and then run tcpdump with -z gzip param. --- burlak@dellicious ~/s/tcpdump $ touch out.pcap burlak@dellicious ~/s/tcpdump $ sudo chown tcpdump:tcpdump out.pcap burlak@dellicious ~/s/tcpdump $ sudo tcpdump -i any -s0 'tcp port 22' -G 10 -z gzip -w out.pcap dropped privs to tcpdump tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes gzip: out.pcap.gz: Permission denied gzip: out.pcap.gz: Permission denied --- Shouldn't be slightly better behavior if tcpdump would create out.pcap.gz before it will drop privileges?
Hi Andrej, but I believe that this is expected. At this point it is gzip, not tcpdump that does not have the access to the file. If you run tcpdump as you described - creating the file with correct ownership first and than running tcpdump - and you do it without gzip, it works, the file gets replaced on every rotation. The case with gzip is that tcpdump calls exec on gzip to compress the file and that operation will not be possible in a directory that is not owned by tcpdump. Also, just a little tip with -z and -G: If you don't specify the name of the output file with a time format or something else that should change every X seconds, the output file will be overwritten(that might be fine) but when gzip gets called and the .gz file with the same name already exists, you will get this prompt every time: gzip: /opt/tcpdump-out.gz already exists; do you wish to overwrite (y or n)? So ideally use the name of the output file as something like this: -w out%F--%T.pcap Regards, Michal
(In reply to Michal Ruprich 🐧 from comment #7) > Also, just a little tip with -z and -G: If you don't specify the name of the > output file with a time format or something else that should change every X > seconds, the output file will be overwritten(that might be fine) but when > gzip gets called and the .gz file with the same name already exists, you > will get this prompt every time: > > gzip: /opt/tcpdump-out.gz already exists; do you wish to overwrite (y or n)? > > So ideally use the name of the output file as something like this: -w > out%F--%T.pcap Thanks, this actually very useful tip for me. :)
No problem, I will keep this open until I decide whether I should remove the patch or not.
FEDORA-2020-bb70d9e9b9 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-bb70d9e9b9
FEDORA-2020-337d2e0966 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-337d2e0966
FEDORA-2020-337d2e0966 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-337d2e0966` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-337d2e0966 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-bb70d9e9b9 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-bb70d9e9b9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bb70d9e9b9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-337d2e0966 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-bb70d9e9b9 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.