allow unprivileged user to run 'makecache' and 'clean' with alternate config

[oliverkurth]

Allow an unprivileged user to run tdnf makecache or tdnf clean. Print out a recommendation if there are insufficient permissions to modify the cache directory. For example, use a configuration that has a cache directory configured where access is possible.

Example:

testuser [ ~ ]$ cat tdnf.conf 
[main]
gpgcheck = 1
installonly_limit = 3
clean_requirements_on_remove = 0
repodir = /etc/yum.repos.d
cachedir = /home/testuser/cache
testuser [ ~ ]$ /build/bld-ph5/bin/tdnf -c ./tdnf.conf makecache
Refreshing metadata for: 'VMware Photon Linux 5.0 (aarch64) Updates'
photon-updates                            3570 100%
photon-updates (primary)                573775 100%
photon-updates (file lists)            2354866 100%
photon-updates (update info)              6146 100%
photon-updates (other)                  256415 100%
Metadata cache created.
testuser [ ~ ]$ 

[sshedi]

Please add a test for both the cases.

[sshedi]

I think adding this in %post of tdnf spec will be a good add-on

%post
test -d %{_var}/cache/%{name} && chmod -R 755 %{_var}/cache/%{name} || :

But assuming that /var/cache/tdnf is the configured repo dir (which holds good in most of the cases)

[oliverkurth]

It shouldn't be needed. When running as non-root, removing the file fails when it is read-only. But when run as root, it can be removed even when read-only. Since the system tdnf runs as root, there is no need to change permissions. makecache/clean wasn't working before the PR for non-root users, and the package is unaware of any non-root uses anyway.

[sshedi]

Agree. I checked in fedora, it allows regular user to do dnf makcache. Should we be in alignment?

[oliverkurth]

Thanks, I checked. I wasn't aware. dnf allows running makecache as an unprivileged user, but it stores the cache in /var/tmp/dnf-<user>-<random uuid>/ (like /var/tmp/dnf-okurth-50ituhym/). Not in the system wide cache - which makes sense, we don't want a regular to have write access to that.

We could consider doing something similar, in another change. This PR would be a prerequisite for that.

[sshedi]

Use gEuid global variable here. If not please make adjustments so that gEuid is populated properly here. I think this can be avoided.

[oliverkurth]

Do you have a reason for this? geteuid() gives the same information (it's not changing), and the performance impact is negligible (if that is your concern).

[sshedi]

Why make a function call when we have a global variable which is dedicated for the exact thing. Redundancy is my concern. And performance as well, even though it is negligible.

[oliverkurth]

Okay, I thought about this - I'll leave it as is. Performance can be ignored here (we already spent more time discussing it than we will ever save). Having a global variable is actually adding redundance, and makes it more complex. For example, if there is an issue, we'd need to figure out if the variable is properly set and so on. But thank you for your advice.