[systemd-devel] setroubleshoot integration.

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 09, 2013 at 12:31:05PM -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/09/2013 11:55 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Jan 09, 2013 at 05:44:02PM +0100, Zbigniew Jędrzejewski-Szmek
> > wrote:
> >> On Wed, Jan 09, 2013 at 11:00:36AM -0500, Daniel J Walsh wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>> 
> >>> One of my goals with setroubleshoot analysys is to get it integrated
> >>> into the journald system.
> >>> 
> >>> In Fedora I am adding
> >>> 
> >>> systemd.journal.send(siginfo.format_text())
> >>> 
> >>> Which will put the setroubleshoot info into the journal, but what I
> >>> really need is to add a key for the process id that created the journal
> >>> entry.
> >>> 
> >>> We had talked about this a while ago with the goal of allowing
> >>> something like
> >>> 
> >>> 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
> > ^relatively easy
> >> for messages with _SYSTEMD_UNIT=setroubleshootd.service (or whatever) and
> >> UNIT=... Would this work for you? This would require setroubleshootd to
Probably SYSTEMD_UNIT would be better here.

> >> 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.
> > A second part would be support for multiline messages. This is another 
> > story.
> > 
> > Zbyszek
> > 
> 
> Well I got two problems, then.  How does setroubleshoot figure out which unit
> file is associated with a pid?  (From python).
We could either expose the C functions (sd_pid_get_session
is already public, and it would be nice to add a Python interface,
shortened_cgroup_path could be easily made public,
cg_pid_get_unit is not public yet either),
or create a rewrite in Python and put it in the systemd-python package,
or even do nothing and let each user rewrite it.

I think option two would be easiest, but maybe option one is worth
pursuing. Option two would be a bit more work, but might help
keep things synchronized in the future. Yeah, it seems best,
since the combined work required to rewrite sd_pid_get_session,
shortened_cgroup_path, and cg_pid_get_unit is pretty big.

> And if the pid is not
> associated with a unit file but with a User or something else (systemd
> itself),  what should I do?
I think just duplicate journald logic:
add SYSTEMD_SESSION,  SYSTEMD_OWNER_UID if possible, or nothing.

Zbyszek