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? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
