@bjornfor, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @joachifm and @offlinehacker to be potential reviewers.

Wonderful! This is exactly what I set up manually. Would much rather just do programs.wireshark.enable = true; 👍

I've changed this to use the setcap wrapper but this removes the possibility to add users to a group to allow this, what do you think?

@globin: What are the effects of that change? Less damage if dumpcap gets compromised, at the expense of allowing everyone on the system to monitor the packets? Would it be possible to use capabilities and give access only to the 'wireshark' group? (I really like the 'wireshark' group feature.)

Added support for setting permissions on setcap wrappers and set the permissions accordingly on wireshark. We don't need a static uid/gid as there is no data associated to them.

Are you fine with this?

@globin Without statid gid this would break with users.mutableUsers = false; (if I remember correctly, that is).

I'm quite sure gids never change on a rebuild, so this should work? I thought the problem was moving data from one machine to another and then not having deterministic uids/gids for the service the data belongs to?

Funny, I remember that I needed to set fixed gids when I moved to mutableUsers = false but I don't see any such restriction now in the code. If it works then 👍!

For what it's worth, I've been successfully using just users.extraGroups.wireshark = {}; without any explicit group ID for quite some time on my system, also inside nixos-container instances.

But it should be mentioned that I don't use mutableUsers = false.

We can always still add it if something breaks, in the worst case one cannot execute wireshark without being root which is what we have right now :)