On 2/22/22 12:14, Boian Bonev wrote:
Hi Dan,
Thanks for the suggestion - I like that way because it gives full
control to
the admin together with the responsibility and does not implicitly do
unexpected things. It is also a clean approach both from user
experience and
packaging point of view, so I will go for that way.
> This is not really an answer to the security question, but if that
remains
> unresolved, you could also introduce a sub package to iotop-c, that
would
> contain a transaction file trigger on the binary and add the
capability. Thus
> user would be able to opt into having iotop-c with the added
capability even
> after upgrades, as long as the sub package is installed.
It's a clever idea but I've never seen packaging used this way. I think
you're saying that the default installation of iotop-c would have
limited capability, and installing the second package would anoint iotop
with the full set of privileges.
Using packaging for this is clever but unintuitive; do we really want to
start it as a new trend? Traditionally, stuff like that was mentioned in
release notes and done as an adiministrative commandline action. Is
there a precedent for using packaging this way?
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
