Not sure if there was ever a bugzilla opened on this, and I have not been able to find one.

[systemd-devel] setroubleshoot integration.
On 01/09/2013 02:49 PM, Lennart Poettering wrote:
> On Wed, 09.01.13 17:44, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl)
> wrote:
> 
>>> systemctl httpd status .... SELinux is blocking httpd read access on
>>> /var/www/index.html setroubleshoot ... run restorecon
>>> /var/www/index.html
>>> 
>>> The only way for systemd to know the setroubleshoot analysys is for
>>> httpd is to include the pid when setroubleshoot writes the journal.
>> Hi,
>> 
>> the way that finding messages pertaining to a certain service works
>> currently is encoded in src/share/logs-show.c, function
>> show_journal_by_unit: - journald adds _SYSTEMD_UNIT=... when it can to
>> messages generated by the services themselves - systemd (PID 1) writes
>> messages about services with UNIT=... and journalds tags them with
>> _PID=1 - COREDUMP writes messages with COREDUMP_UNIT=...
>> 
>> I think it would be realitively to extend show_journal_by_unit() to
>> check for messages with _SYSTEMD_UNIT=setroubleshootd.service (or
>> whatever) and UNIT=... Would this work for you? This would require
>> setroubleshootd to find out the unit name on its own. Actually, this
>> might be for the better, since by the time that journald gets the
>> message, the PID might be long gone, and setroubleshootd has more
>> knowledge.
> 
> Oh, uhm, I was envisioning a much simpler, more generic solution for this.
> Something as simple as this:
> 
> We'd define a new special field OBJECT_PID. If this is included in a 
> message, and that message comes from a privileged service, then journald 
> will automatically add in OBJECT_EXE, OBJECT_UID, OBJECT_COMM, OBJECT_UNIT
> ... from /proc.
> 
> That way, all setroubleshoot would have to do is add this one property to
> its messages, and systemd would do the rest. In fact, not only 
> setroubleshoot could make use of that. For example, PolicyKit might too.
> Much like setroubleshoot it needs to log messages about specific processes
> (in this case clients), and could benefit from implicit augmentation of the
> message by journald.
> 
> Eventually we might want to add the same for OBJECT_DEVICE or so, in case
> device managers want to logs things about devices or so.
> 
> Implementation of this scheme on the systemd side should be fairly simple,
> but even more so on the setroubleshoot side.
> 
> Does this make sense?
> 
> Lennart
> 
I like the idea, (Less work for me. )