RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 766167 - RFE: provide a command/signal for certmonger to send after renewing cert
Summary: RFE: provide a command/signal for certmonger to send after renewing cert
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: certmonger
Version: 6.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: IDM QE LIST
URL:
Whiteboard:
: 782972 (view as bug list)
Depends On: 761188 790967
Blocks: 736854 750334 854383
TreeView+ depends on / blocked
 
Reported: 2011-12-10 19:05 UTC by Dmitri Pal
Modified: 2012-09-04 20:40 UTC (History)
6 users (show)

Fixed In Version: certmonger-0.54-1.el6
Doc Type: Enhancement
Doc Text:
Clone Of: 761188
Environment:
Last Closed: 2012-06-20 13:43:06 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0833 0 normal SHIPPED_LIVE certmonger bug fix and enhancement update 2012-06-19 20:49:14 UTC

Description Dmitri Pal 2011-12-10 19:05:06 UTC 
+++ 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.
Comment 1 Dmitri Pal 2012-01-31 16:51:15 UTC 
*** Bug 782972 has been marked as a duplicate of this bug. ***
Comment 2 Nalin Dahyabhai 2012-02-14 17:11:55 UTC 
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.
Comment 3 Nalin Dahyabhai 2012-02-15 07:23:25 UTC 
(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.
Comment 5 Nalin Dahyabhai 2012-02-16 20:48:02 UTC 
(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.
Comment 6 Kaleem 2012-04-30 11:24:57 UTC 
Verified.

Certmonger Version:
===================
certmonger-0.56-1.el6.x86_64


Successful beaker job:
======================
https://beaker.engineering.redhat.com/jobs/225467
Comment 8 errata-xmlrpc 2012-06-20 13:43:06 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.