[systemd-devel] setroubleshoot integration.

Lennart Poettering lennart at poettering.net
Wed Jan 9 11:49:47 PST 2013


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

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list