[systemd-devel] [ANNOUNCE] Journal File Format Documentation

[Lennart Poettering]

On Tue, 23.10.12 23:43, Alexander E. Patrakov (patrakov at gmail.com) wrote:

> 
> 2012/10/21 Lennart Poettering <lennart at poettering.net>:
> > Heya,
> >
> > I have now found the time to document the journal file format:
> >
> > http://www.freedesktop.org/wiki/Software/systemd/journal-files
> >
> > Comments welcome!
> 
> The doc says these two things:
> 
> 1) The format is designed to be read and written via memory mapping
> using multiple mapped windows.
> 2) A reader should verify all offsets and other data as it reads it.
> This includes checking for alignment and range of offsets in the file,
> especially before trying to read it via a memory map.
> 
> I am worried by the fact that it is not specified what happens if a
> reader tries to read a file manipulated by a bad writer. Namely, the
> one that repeatedly writes some valid data into the log in order to
> lure readers into this area, and then truncates or overwrites it in
> hope to trigger a SIGBUS or something worse in readers.
> 
> IMHO if a reader cannot trust the concurrent writer of the file to
> behave nicely, mmap-based reading should be outright banned. So please
> - either establish and document some kind of trust model between the
> reader and the writer, or ban mmap-based reading of non-archived
> journal files completely.

Yeah, we never made this explicit or documented this, but precisely this
is the reason why per-user journal files which we split off for access
control reasons are not actually owned by the users, but simply
accessible to users via file systems ACLs: we want to ensure that users
cannot truncate the files to cause journald (or another journalctl) to
SIGBUS. With ACLs we can give users read access without the ability to
modify their own files.

With the journal we try to follow the rule that for mmap() there might be
a security boundary between readers and writers, but if so, then it must
be privileged on the writer side and unprivileged on the read side, and
this must be reflected on the access rights of the file.

This probably deserves documentation somewhere. (added to the todo list)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.