Dne 22.7.2017 v 23:26 Neal Gompa napsal(a): > On Sat, Jul 22, 2017 at 5:11 PM, Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: >> On Sat, Jul 22, 2017 at 02:06:42PM -0600, Chris Murphy wrote: >>> On Sat, Jul 22, 2017 at 1:57 PM, Matthew Miller >>> <mattdm@xxxxxxxxxxxxxxxxx> wrote: >>>> On Sat, Jul 22, 2017 at 01:42:11PM -0600, Chris Murphy wrote: >>>>> I don't know what things the unprivileged user can do other than >>>>> search and info. But off hand I'd say an unprivileged user should not >>>>> be able to download metadata. Use one /var/cache/dnf always. And if >>>>> it's stale, just inform the user. Only update the cache if the command >>>>> is issued by root. >>>> I dunno; what harm is there in giving the ability to use a separate >>>> user cache for queries? This allows you to do things like repoquery as >>>> an unprivileged user for repos that aren't enabled by default. >>> I'm fine with a layered approach, *if* a repo db does not exist for >>> root, then it's OK for a user copy to be downloaded, but how about one >>> for all users to share rather than each user getting a downloaded copy >>> of the same thing? >> It'd probably require rearchitecturing the way that caching works. >> Current implementation does the best (maybe ignoring some minor bugs) >> of what is possible in a secure way with unprivileged users in current >> design, but we should be able to do better. Namely, create a polkit-aware >> daemon which will download metadata on demand, and then make root and >> the users forward all metadata download requests to this daemon. >> This would avoid any duplicate downloads, without the need to run >> dnf searches as root. >> >> (Ideally, dnf would also have strong tmpfiles.d policy to clean up all >> caches after ~1 month of unuse, so that if a user requests some repo, >> the disk space is not permanently wasted.) >> > So... like dnfdaemon, except with less capabilities? > > I already proposed it to DNF upstream while ago due to different use case: https://bugzilla.redhat.com/show_bug.cgi?id=1382224#c15 Vít _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
