Hi, I recently noticed a failing cron job because setpriv was missing on my system. # cat /etc/cron.weekly/pfl #!/bin/sh setpriv --reuid=portage --regid=portage --clear-groups nice /usr/bin/pfl >/dev/null # /etc/cron.weekly/pfl /etc/cron.weekly/pfl: line 2: setpriv: command not found The presence of the setpriv binary is controlled by the caps use-flag for util-linux so it should be added to pfl's RDEPEND.
Thanks for the report. This is fixed in Git with pfl-3.0.1-r2.
Can't you rewrite cronjob to do something like > exec su portage -s /bin/sh -c 'nice /usr/bin/pfl >/dev/null' 2>/dev/null to avoid setpriv depedency?
(In reply to Thomas Deutschmann from comment #2) > Can't you rewrite cronjob to do something like > > > exec su portage -s /bin/sh -c 'nice /usr/bin/pfl >/dev/null' 2>/dev/null > > to avoid setpriv depedency? Of course I can. I looked for solutions in bug #679772. I found setpriv suitable and chose it. Maybe I just missed the obvious solution.
(In reply to Daniel Pielmeier from comment #3) > (In reply to Thomas Deutschmann from comment #2) > > Can't you rewrite cronjob to do something like > > > > > exec su portage -s /bin/sh -c 'nice /usr/bin/pfl >/dev/null' 2>/dev/null > > > > to avoid setpriv depedency? > > Of course I can. I looked for solutions in bug #679772. I found setpriv > suitable and chose it. Maybe I just missed the obvious solution. Okay I tried to remember why I chose setpriv. When doing the research I stumbled upon a stackoverflow question [1] where su was initially listed a non-option. Then I found a stackexchange [2] question. Especially answer [3] mentioned an excerpt from the su man-page which explicitly states that privileged user should use runuser or setpriv instead of su itself. An earlier comment [4] links to a document stating that su should not be abused for dropping privileges. Thus I settled to go with setpriv from util-linux. However after your comment and some more digging I found that there are more implementations of su. One from the sys-apps/util-linux package and another one from the sys-apps/shadow package. Gentoo apparently uses the version from shadow. The excerpt from the man-page is from the util-linux version, the shadow version apparently does not distinguish between privileged and unprivileged users. This however does not mean the implementation of shadow is better (or worse). I have not that much experience and can not decide this. If somebody tells me I can savely use su from shadow, i have no problem with changing it. If not I will stick with setpriv from util-linux. Besides when running su as you recommended it I get the following: > su: Authentication service cannot retrieve authentication info > (Ignored) The command itself executed just fine but there seems to be an issue with pam. [1] https://stackoverflow.com/questions/24251474/how-to-drop-root-privileges-from-a-posix-shell-script [2] https://unix.stackexchange.com/questions/132663/how-do-i-drop-root-privileges-in-shell-scripts [3] https://unix.stackexchange.com/a/479308 [4] https://unix.stackexchange.com/a/353698
Oh, didn't expect such a research. Well, I wouldn't care that much: I took my example from sys-apps/man-db cronjob (base-system package). Even sys-apps/portage install logrote script which uses su. Using my suggestion (with fixed/normalized output handling of course) should be safe.
(In reply to Thomas Deutschmann from comment #5) > Oh, didn't expect such a research. Well, I wouldn't care that much: > > I took my example from sys-apps/man-db cronjob (base-system package). > Even sys-apps/portage install logrote script which uses su. > > Using my suggestion (with fixed/normalized output handling of course) should > be safe. As this was the first time I had to deal with dropping privileges I thought I might as well read a bit about it. After reading some more I think I will stick with using setpriv. The man-page says: > It is a simple, non-set-user-ID wrapper around execve(2), and can be used to > drop privileges in the same way as setuidgid(8) from daemontools, chpst(8) from > runit, or similar tools shipped by other service managers. From [1], setuidgid and chpst fall into the category of dropping privileges instead of adding them and also do not fall into an interactive mode. So I think the additional dependency is justified. [1] https://unix.stackexchange.com/a/353698
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8c429919d7ede49af0bf8e8b718001748934953a commit 8c429919d7ede49af0bf8e8b718001748934953a Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-07-21 20:59:05 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2019-07-21 20:59:21 +0000 app-portage/pfl: hide sys-apps/util-linux RDEPEND behind USE flag Bug: https://bugs.gentoo.org/690290 Package-Manager: Portage-2.3.68, Repoman-2.3.16 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> app-portage/pfl/pfl-3.0.1-r2.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
> app-portage/pfl: hide sys-apps/util-linux RDEPEND behind USE flag While looking at so many things I completely forgot about the cron script being conditionally installed. Thanks a lot.
