[systemd-devel] Journalctl and sshd disconnects

[Jake Rooney]

Hi Lennart,

Thanks for the reply.

I can't understand the user-generated sshd log being put into it's own
journal out of distrust, isn't that just paranoia? I don't see the
practicality of it. Either way, it's still getting logged. Does it
matter that it's not in the main journal? Can you elaborate on this
please?

As for the _EXE and _COMM 'race' issue you mentioned; are you really
sure that's a kernel problem..? I'm not clear enough (or qualified
enough) on the internals to speculate, but it sounds more like a
mishandling on systemd's behalf...

Also: I'd really like to see regular expression capability built into
journalctl :)

Cheers,

Jake


On 20 November 2012 18:40, Lennart Poettering <lennart at poettering.net> wrote:
> On Fri, 26.10.12 11:11, Jake Rooney (tehekaj at gmail.com) wrote:
>
>> Hi,
>>
>> Couple of questions...
>>
>> At the moment (195) journalctl  _SYSTEMD_UNIT=sshd.service prints out
>> most sshd logs, but skips user disconnections/logouts. These seem to
>> be logged under the UID of the user that logged out and are stored in
>> a separate journal. Why is this?
>
> This is because sshd gets moved into the per-session cgroup, and that's
> what we are looking for.
>
> The disconnect message is that generated from UID 0 or the actual user?
> If it is run as UID of the user we really shouldn't trust the code, and
> hence splitting things off in the per-user journal sounds like the right
> thing to do?
>
>> journalctl _COMM=sshd matches all logs, including disconnects, but
>> _EXE=/usr/sbin/sshd skips disconnections. There seems to be some
>> inconsistency here, so I was wondering what's the "best" way to filter
>> for all sshd info, rather than having to resort to dumping the journal
>> and grep'ing.
>
> This part really sounds as if it is simply an instance of a common race
> that we still need to fix in the kernel: the journal will receive
> UID/GID/PID credentials of the sender of a message along with the
> message, and then uses that to lookup _EXE, _COMM and other fields. Now,
> if by the time where the message has been received and we begin to
> lookup up those extra fields the client side already exited we cannot
> gather that information.
>
> This is someting to fix in the kernel: we'd really like an interface
> that can send along _EXE, _COMM and suchlike right-away, so that we have
> it without having to actually gather it explicitly, so that the race is
> gone.
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.