Hide Forgot
+++ This bug was initially created as a clone of Bug #761188 +++ Description of problem: certmonger renews certificates just fine but in most, if not all, cases the server it renews a cert for will need to be restarted in order to see it. It would be handy if one could provide a command (or signal) for certmonger to send after successfully renewing a cert. For example, it could run: /sbin/service httpd reload This might raise some existential security questions, particularly with SELinux. --- Additional comment from nalin on 2011-12-07 16:45:26 EST --- Emitting a signal is more common for services, and doesn't require any additional privileges to be granted in the SELinux policy. --- Additional comment from nalin on 2011-12-08 17:18:44 EST --- If we implement properties, and one of them reflects the contents of the certificate associated with a given request, then the client can wait for a signal that the contents of that property have changed to a non-empty value.
*** Bug 782972 has been marked as a duplicate of this bug. ***
Two approaches here. In 0.53 or later, the object which the D-Bus service provides for managing the certificate will begin to emit a "SavedCertificate" after it successfully saves a certificate. Additionally, most of the information is now exposed as D-Bus properties, and the usual "PropertiesChanged" signal will now be emitted. A lower-effort alternative for clients is to have the daemon also offer the ability to just run a specified command at this step. This turns out to be kind of tricky - while we currently only allow root to talk to the system daemon, while we can add the ability to fire off an arbitrary command now, if we ever allow access for unprivileged users in the future, this would be easily abused. Tracking the UID of the client that last set the command that we'll run, and dropping to that user's privileges before running that command, might be a reasonable way to do it.
(In reply to comment #2) > Tracking the UID of the client that last set the command that we'll run, and > dropping to that user's privileges before running that command, might be a > reasonable way to do it. Okay, we're going with that. The command can be specified as an argument for the new -C option for a number of getcert's functions.
(In reply to comment #3) > Okay, we're going with that. The command can be specified as an argument for > the new -C option for a number of getcert's functions. Note that potentially dropping to the calling user's privileges and then executing an arbitrary command requires more permissions from the SELinux policy than we previously needed. That conversation is happening in bug #790967, and feedback on what the policy needs to start allowing would be appreciated there.
Verified. Certmonger Version: =================== certmonger-0.56-1.el6.x86_64 Successful beaker job: ====================== https://beaker.engineering.redhat.com/jobs/225467
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0833.html