Created attachment 394514 [details] pgagent.confd-r1 When pgAgent runs its scheduled tasks, it runs the database task as its database user, but it runs the batch jobs (shell scripts) as the user under which the daemon is running. Right now we always run pgagent as root, so anyone who can schedule tasks essentially has root on the box. The daemon itself runs fine as an unprivileged user, it only needs two things: 1. Write access to the log file 2. A ~/.pgpass with credentials (you needed this anyway, with root) I made two small modifications to the init.d/conf.d files to allow this. The corresponding ebuild revbump is trivial but I could post that too if you prefer.
Created attachment 394516 [details] pgagent.initd-r1 Updated init.d file, it passes -user "${PGA_SYSTEM_USER}" (which is a new conf.d variable) to start-stop-daemon to drop privileges when PGA_SYSTEM_USER != root.
You're right, this should run as an unprivileged user. However, I think there's a better way to implement this. I'll look into this over the next few days.
Thanks for taking a look. There are cases where you want pgagent to run as root (if the shell scripts need root, to restart a daemon or whatever). But in my case I have a DBA who doesn't know much about Linux administration so I'd like him to be able to break the database but not the OS. A totally-unprivileged user works fine for that. I looked into it but I didn't see a better way to limit the system permissions that the pgagent admin has.
Created attachment 488832 [details] pgagent-3.4.0-r3.ebuild
Created attachment 488834 [details] pgagent.initd-r2 I've learned a lot about init scripts in the meantime, and I think this is a much better approach: hard-code the "pgagent" user in the ebuild, and don't let the user change it. If he wants to make "pgagent" a super-user, he can do that. This lets us use checkpath to ensure that the log file permissions are OK, and makes the init script nice and clean. A new conf.d file is no longer necessary. (and the ebuild is EAPI=6 now)
(In reply to Michael Orlitzky from comment #5) > Created attachment 488834 [details] > pgagent.initd-r2 > > I've learned a lot about init scripts in the meantime, and I think this is a > much better approach: hard-code the "pgagent" user in the ebuild, and don't > let the user change it. If he wants to make "pgagent" a super-user, he can > do that. This lets us use checkpath to ensure that the log file permissions > are OK, and makes the init script nice and clean. A new conf.d file is no > longer necessary. > > (and the ebuild is EAPI=6 now) This looks good to me. I invite you to add yourself to the PostgreSQL project (even if all you care for is pgagent), and add your changes to the tree. However, why root:pgagent for the log file? Why not pgagent:pgagent and 0600?
(In reply to Aaron W. Swenson from comment #6) > > I invite you to add yourself to the PostgreSQL project (even if all you care > for is pgagent), and add your changes to the tree. Ok, thank you. I'll be upgrading to this new ebuild/init on a few production servers tonight or tomorrow, and if it all goes smoothly, I'll commit after that. > However, why root:pgagent for the log file? Why not pgagent:pgagent and 0600? Spur of the moment decision... having it group-pgagent rather than owner-pgagent prevents some things like the pgagent user running "chmod" on it. Is there a benefit to having it pgagent:pgagent?
Just committed: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5b41b4fb3fc10a2b4046fb2c8c97d9b824505f20
