https://bugzilla.redhat.com/show_bug.cgi?id=1764368 Petr Menšík <pemensik@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |pemensik@xxxxxxxxxx Assignee|nobody@xxxxxxxxxxxxxxxxx |pemensik@xxxxxxxxxx --- Comment #3 from Petr Menšík <pemensik@xxxxxxxxxx> --- /root/.ducrc is not possible and very wrong. It should be quite simple to just make that directory default, if uid=0 was detected. Runtime from the code. Just make some ifs in the code. Or pass db directory to service parameters. System level service would use system cache, user started service might use just home cache. It might also just check access rights to default system cache. If no right to write there, just create and use cache directory in $HOME/.cache/duc. Please take into account it might run under sudo, where $HOME is not root's. It might work to provide also shell wrapper, which would change DUC_DATABASE. For example: #!/bin/sh if [ "$(id -u)" = 0 ]; then DUC_DATABASE=/var/cache/duc fi duc "$@" But I think getuid() kernel call in the code would be better than similar shell wrapper. Check man 2 getuid. But I like access("/var/cache/duc", W_OK) check more, because it would allow also access by group rights. It is quite unusual to provide own selinux policy files. Why are they required? Also, it seems wrong to have privileged duc index command and duc gui for displaying it. I think duc-index separate command would be more secure. Only it would have elevated privileges to read other users data. Reading indexed data should not require any extra privileges, just read permissions to indexed database. But current binary cannot set different selinux contexts to different actions. Maybe duc-indexd would be better name, to indicate it is usually run as a daemon, indexing service. It might work with shell wrapper around duc index, which would have different context. Similar to what I used above. -- 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 Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
