[systemd-devel] [RFC/PATCH] journal over the network

Thomas Bächler thomas at archlinux.org
Tue Nov 20 02:17:17 PST 2012


Am 20.11.2012 02:26, schrieb Lennart Poettering:
> On Mon, 19.11.12 11:14, Thomas Bächler (thomas at archlinux.org) wrote:
> 
>> Am 19.11.2012 01:21, schrieb Zbigniew Jędrzejewski-Szmek:
>>> They are parsed and stored
>>> into a journal file. The journal file is /var/log/journal/external-*.journal
>>> by default, but this can be overridden by commandline options (--output).
>>
>> What about /var/log/$MACHINE_ID/, isn't it the right place for these?
> 
> I doubt we can do that. The machine ID isn't really something people
> might want to specify on the command line. But if it isn't specified on
> the command line we'd have to get this data from the remote host, but
> that host we only trust enough to pull out its data, but we cannot allow
> it to choose the file path where we store things in, because that it
> could use to overwrite data from other hosts (including our local one)
> by simply pretending that some specific machine ID was his, which
> actually isn't.

That's a very long sentence - I still think I get your point.

My thoughts on this:

1) If we can configure to allow a specific host to log only to certain
machine IDs, we can easily filter the incoming messages.

2) There should be a solution for the trust issue. The remote host could
authenticate in some way, or even sign the messages. I don't want
messages from any untrusted source in my logs, no matter in what path.

IMO, in any scenario where you want to store remote log messages, you
want to make sure that they're coming from the right place and have not
been tampered with. It is reasonable to expect the admin to perform some
configuration here.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20121120/2cc730bd/attachment.pgp>


More information about the systemd-devel mailing list