I observed that the dumpcap program, provided by wireshark-cli, instead of being owned by the group wireshark, is owned by usbmon. This prevents the user from using tshark without being a member of not only wireshark, but also the usbmon group, which I think is not intended. This is probably caused by the packages preinstall script: ``` $ rpm -q --scripts wireshark-cli preinstall scriptlet (using /bin/sh): # generated from wireshark.sysusers getent group 'wireshark' >/dev/null || groupadd -r 'wireshark' || : getent group 'usbmon' >/dev/null || groupadd -r 'usbmon' || : postinstall scriptlet (using /bin/sh): # skip triggering if udevd isn't even accessible, e.g. containers or # rpm-ostree-based systems if [ -S /run/udev/control ]; then /usr/bin/udevadm trigger --subsystem-match=usbmon || : fi ``` Reproducible: Always Steps to Reproduce: Install wireshark-cli Actual Results: dumpcap is owned by usbmon Expected Results: dumpcap is owned by wireshark Additional Information: I’m actually unsure whether this is really intended or not. However, dumpcap is not used for USB monitoring, but for network captures: https://www.wireshark.org/docs/wsug_html_chunked/AppToolsdumpcap.html > Dumpcap is a network traffic dump tool. It captures packet data from a live network and writes the packets to a file. Dumpcap’s native capture file format is pcapng, which is also the format used by Wireshark. If this is really intended, feel free to close the bug report.
Hi, I don't know how you figured that out. dumpcap is owned by wireshark, not usbmon: $ ls -la /usr/bin/dumpcap -rwxr-x---. 1 root wireshark 153200 Sep 1 02:00 /usr/bin/dumpcap Could you please elaborate a bit on why you think otherwise? Regards, Michal Ruprich
Hi, I used a similar command to yours. I’m sorry for the indirection, but I posted the output as a screenshot on the Fedora forum: https://discussion.fedoraproject.org/t/fedora-sway-atomic-improper-group-for-dumpcap-wireshark-cli/167883 You can see the output of the command where usbmon is shown as the group attached to dumpcap. Additionally, I had to add my user to the usbmon group in order to use tshark, otherwise it was failing with a permission problem, which as it turned to be, was because the wrong group was set on dumpcap. Right now I’m tweaking my system and I don’t have access to the affected installation anymore, but as mentioned in the forum, it was a Fedora Sway Atomic flavor (Fedora 42), so I expect the problem to be easily reproducible. I’ll check again next time I perform a fresh installation and report back if the problem is still present. Regards
The post scripts don't change any ownership of dumpcap. /usr/bin/dumpcap also has explicit ownership set in the %files section of the specfile as follows: %attr(0750, root, wireshark) %caps(cap_net_raw,cap_net_admin=ep) %{_bindir}/dumpcap Tested with vanilla F41, F42, F43 and Rawhide, everything works as expected. This has to be something specific to how the Sway Atomic version of Fedora is being deployed.
Hi, looking into the image that you are using, there is something wrong how it is being setup in the first place. I followed your instructions for installing the fedora-atomic-kokoriko and after the second rebase using this command: $ rpm-ostree rebase ostree-image-signed:docker://ghcr.io/cbenoit/atomic-kokoriko:latest I can see that dumpcap is owned by greetd (whatever that is): $ -rwxr-x---. 1 root greetd 161544 Jan 1 1970 dumpcap Unfortunately I am not familiar with the process how the particular image is being deployed but there is nothing wrong with how wireshark is being installed in Fedora. I hope this helps. Michal Ruprich
Hi, I have no idea what’s happening with the group of this file, all I am doing is using BlueBuild to create the image the way it’s intended (https://blue-build.org/). I see in your case the group is greetd. For me, the first time, it was usbmon. I reinstalled the OS yesterday and the group was 965 (orphaned, without name). Now I updated the image to include with a new service: keyd, and this time the group is keyd. Maybe it’s not a problem directly in the wireshark packaging, but there is definitely something wrong happening here. Am I reporting this issue at the wrong place?
Hi. Sorry for the double mail. I tried to install Fedora 42 Atomic Sway from scratch, and applied the wireshark-cli package as a layer: # rpm-ostree install wireshark-cli Now the group is properly set to wireshark. It occurred to me that BlueBuild is not a project attached to the Fedora project, so I agree with your decision to close this ticket. Thank you for taking time to look into this, I’m really sorry for having used the wrong channel to report the issue. Regards Benoît Cortier
Hi, no problem, it was actually interesting to investigate for a while. I don't know if there is a different bugzilla for these other Fedora flavors. Maybe the BlueBuild itself has some? Regards, Michal Ruprich
I wonder if someone here - https://blue-build.org/learn/troubleshooting/ - could be able to help with that.
Hi again, Thank you for following up! I investigated further on my side, and I think I finally found out the problem. In case that’s of interest to you, or anyone else reading this ticket, let me elaborate my findings below. In fact, the nature of the problem is accurately described in an article from LWN.net: > Most of the time UID and GID assignments will remain static between updates. As > Zbigniew Jędrzejewski-Szmek pointed out on the fedora-devel mailing list when > raising the UID/GID drift problem, as long as the list of packages remains the > same, the installation order of the packages is stable and will always get the > same UIDs/GIDs. > > > But we can get different assignments if the package installation order changes, > > for example because of some dependency change, or more/less packages are > > installed, or when one of the packages defines a new user/group. In general, we > > can expect the uid/gid assignments to change regularly. > > He goes into detail using the opencryptoki package as an example. That package > creates the pkcs11 group when installed, and its GID is selected at that time. > The package has a file in its payload, /etc/opencryptoki/strength.conf, that is > owned by the pkcs11 group. An rpm-ostree or bootc image is built that includes > that package, and it receives the GID 999 (for example) from the range of > GID numbers that are available to system accounts. Users deploy that image to > their systems. The /etc/opencryptoki/strength.conf file is now owned by GID 999 > because filesystems store ownership as numbers and not user or group names. > > Later, when a new image is created from package updates, something changes in > the package order. This means that the pkcs11 group gets GID 998 this time. Note > that files in /etc (or /var) are not necessarily overwritten when there is a new > image, so some of the files that have group ownership stored as GID 999, such > as /etc/opencryptoki/strength.conf, may persist even though the pkcs11 group is > now GID 998. So when users update to the new image, some files are owned by a > GID that either maps to a different group in /etc/group or to no group at all. (https://lwn.net/Articles/1018082/) Sounds exactly like what is happening to the dumpcap binary in my image. I believe Fedora’s official images such as Fedora Atomic Sway and the others _are_ vulnerable too, but the problem does not seem to affect system overlays via rpm-ostree, _and_ it’s unlikely that wireshark-cli will be installed by default in any official flavors. As mentioned in the LWN’s article, the opencryptoki package is using tmpfiles to correct the group of some files: > z /etc/opencryptoki/p11sak_defined_attrs.conf 0640 root pkcs11 - > z /etc/opencryptoki/strength.conf 0640 root pkcs11 - (https://src.fedoraproject.org/rpms/opencryptoki/blob/f42/f/opencryptoki-3.24.0-tmpfiles-image-mode.patch) Unfortunately, it’s not possible to use the same tmpfiles-based approach for files in /usr, because in the case of the ostree-based flavors, it’s read-only. To address this in my custom image, I used this approach: https://github.com/CBenoit/fedora-atomic-kokoriko/commit/688aae9f50662f8086f892a6ce6fdfaf6db0bdf5 - Configure a fixed GID for wireshark (e.g.: 61184) via sysusers (when the wireshark group is created for the first time, it will get this GID). - During the build, set /usr/bin/dumpcap's group to that fixed GID. - One-shot service to set the wireshark GID to the fixed one, in case the group was already created prior to rebasing. Obviously, it’s not an ideal solution, and there are problems with that approach. I was hoping I could find a reliable approach that we could apply to the wireshark-cli package itself, like for opencryptoki, but I couldn’t find such a solution as of today, but this solution is "good enough" for my custom image (I’m not setting the wireshark GID to any other file in the system, and I’m pretty confident there will be no conflict with the GID I fixed). I’m curious if you have any idea? Otherwise, the ticket can probably stay closed, as I suspect there is simply no possible fix at the package-level as of today, and the general is issue is already acknowledged by the Fedora project. Regards, Benoît Cortier