https://bugzilla.redhat.com/show_bug.cgi?id=1442547 --- Comment #6 from Neal Gompa <ngompa13@xxxxxxxxx> --- Issues: >[!]: Package must own all directories that it creates. > Note: Directories without known owners: /usr/share/gir-1.0, /usr/share > /gtk-doc, /usr/share/dbus-1, /usr/share/vala/vapi, > /usr/share/dbus-1/services, /usr/share/gtk-doc/html/gsignond, > /usr/share/gtk-doc/html, /usr/lib64/girepository-1.0, > /usr/share/dbus-1/interfaces, /usr/share/vala Some of the ownership issues can be ignored (like /usr/share/vala, /usr/share/vala/vapi, /usr/share/gtk-doc, /usr/share/gtk-doc/html, /usr/lib64/girepository-1.0). However, gsignond needs a runtime requires for dbus%{?_isa}, as it is necessary for its functionality to be useful. The doc subpackage file entry needs the asterisk removed, because it's preventing RPM from considering that it should own /usr/share/gtk-doc/html/gsignond too. >Rpmlint: > gsignond.x86_64: E: missing-call-to-setgroups-before-setuid /usr/bin/gsignond Apparently, gsignond was a setuid binary on purpose. In the code, it uses seteuid() in daemon/main.c and common/gsignond-storage-manager.c. However, it seems to gracefully fail when it does that. That said, apparently it's not doing setegid() before using seteuid() in common/gsignond-storage-manager.c (or in the ostro/tizen code, but I don't care much about them). From what I can tell, it's setuid so that it can drop privileges as a daemon and set storage directories to be individually owned by specific users. In Fedora, we prefer if this can function with file capabilities, as they are more granular and when used well, can limit the damage caused by vulnerabilities to privileged applications. Please file a bug upstream to see if this can be appropriately resolved. Action items: * Fix the directory ownership issues * File a bug upstream about the rpmlint error and to request gsignond to work with file caps instead. - https://fedoraproject.org/wiki/Features/RemoveSETUID - https://www.mankier.com/7/capabilities -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx