Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#42182 - [wireshark-cli] Handle wireshark group already existing

Attached to Project: Community Packages
Opened by Gabriel Potkány (gadelat) - Tuesday, 30 September 2014, 07:07 GMT
Last edited by Timothy Redaelli (tredaelli) - Wednesday, 01 October 2014, 08:45 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Timothy Redaelli (tredaelli)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

I created & added myself to wireshark group before installing this package and rights for capture did not work because there was assigned non-existent group id to dumpcap. It tries to add group wireshark and then assumes it created ok. If it fails, it blindly assings group id 150.
This task depends upon

Closed by  Timothy Redaelli (tredaelli)
Wednesday, 01 October 2014, 08:45 GMT
Reason for closing:  Not a bug
Comment by Daniel Micay (thestinger) - Tuesday, 30 September 2014, 07:45 GMT
The group name is reserved in the UID/GID database so I don't think it's doing anything wrong. It could check for the group existing, but it doesn't necessarily have the right ID and it has no way of knowing what the group was being used for and if orphaned files will be left behind with an ID that's no longer assigned. I don't think it can be considered a bug without a better way of dealing with users/groups in packages. The fault lies with whoever / whatever created a user/group with a reserved name or id.
Comment by Gabriel Potkány (gadelat) - Tuesday, 30 September 2014, 08:59 GMT
Well script fails to create group and assumes it did, so it doesn't work as expected. I think there is more users with this problem than it seems, because wireshark group is listed in https://wiki.archlinux.org/index.php/users_and_groups#Software_groups which is linked in https://wiki.archlinux.org/index.php/General_Recommendations which is linked in https://wiki.archlinux.org/index.php/installation_guide and some users want to create all desired groups beforehand at once and be done with it. If user do this, he has no feedback from system that this is wrong.

I think script should use id of already existing wireshark group if it does exist, because come on, what else could group named "wireshark" be used? Or at least notify user that something is wrong (failed to create group, ect)
Comment by Daniel Micay (thestinger) - Tuesday, 30 September 2014, 09:02 GMT
You will have problems if you create users / groups reserved by packages. It's a problem with how users and groups are managed in Arch in general, not specifically the Wireshark package.
Comment by Doug Newgard (Scimmia) - Tuesday, 30 September 2014, 14:25 GMT
How do you propose this be handled? /usr/bin/dumpcap is set to GID 150 in the PKGBUILD, if you have a group with a different GID, things fail.

Maybe the install should just die completely if you already have a non-GID 150 wireshark group?
Comment by Gabriel Potkány (gadelat) - Tuesday, 30 September 2014, 16:08 GMT
I have not enough knowledge about how groups in Arch Linux (or generally in Linux) work, but is setting group id to number 150 right way? Is group 150 in system reserved for group named "wireshark"?
If yes, why system doesn't automatically assign this GID to group named "wireshark" manually created by user?
If not, what happens when something else (aur package etc.) assigns this GID to other group name first?

I guess second answer is correct and there isn't actually reserved GID 150 for group named "wireshark" in system and any package can do this instead of wireshark-cli. And if that's the case, current behavior of this package can create even more serious problems. I don't think this package should assign GID, but it should rather assign group name.

If this isn't suitable solution, this package should at least generate confirmation/warning. I don't think it should generate error, it's not so big problem. I propose to choose some of these kind of messages:
1)Warning: Group "wireshark" already exists, overwrite? (y/n)..
2)Warning: Failed to create "wireshark" group. Sniffing without root privileges won't work. Remove the group and reinstall package for this feature to work.

User will by this point remember that he added that group manually and what it was for and even if he doesn't, chance that he uses wireshark group for something else is pretty slim, he won't break anything important.

I just ask this package for at least some feedback if it failed to do something, because right now user has no idea that something was set wrong (group id of non-existent group).
Comment by Doug Newgard (Scimmia) - Tuesday, 30 September 2014, 17:11 GMT
"I don't think this package should assign GID, but it should rather assign group name."

Names are irrelevent, the only thing that matters is the GID. It's similar to a URL, the URL itself doesn't really get you much besides a way to look up the IP. Your suggestion here will not work at all, as the packager needs to know the GID at build time to be able to assign it.

As for you question about whether it's reserved, yes it is: https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database
Comment by Gabriel Potkány (gadelat) - Tuesday, 30 September 2014, 18:50 GMT
Not quite good comparison. Both GID and name of group are unique, system doesn't allow to add two groups with same name. So I don't see much appeal to keep using GID. That's why creating wireshark group by this package currently fails if there already is group named wireshark. Anyway, I just wanted to make this easy. It's easy to remove "-g 150", but if it's not suitable, finer check is needed to put in place, like checking if it exists and use GID of already existing group instead.

"Your suggestion here will not work at all, as the packager needs to know the GID at build time to be able to assign it."
Really? I removed "-g 150" from pkgbuild and built and installed it myself and it works great.

Another problem with this is this: your package creates group by GID when installing, but when removing package, it removes group by name. Pretty inconsistent, you said you want to be sure that group which already exists is group we need, but you don't care about that when uninstalling.
Comment by Doug Newgard (Scimmia) - Tuesday, 30 September 2014, 23:26 GMT
""Your suggestion here will not work at all, as the packager needs to know the GID at build time to be able to assign it."
Really? I removed "-g 150" from pkgbuild and built and installed it myself and it works great."

Then take that package to another computer. It won't work.

It's become obvious you don't understand how group management works in Linux. tredaelli, time to close this?

Loading...