What are reasonable blockers for making journald the default logger in F19?

[Simo Sorce]

On Wed, 2012-10-17 at 17:45 +0200, Lennart Poettering wrote:
> On Wed, 17.10.12 10:44, Matthew Miller (mattdm at fedoraproject.org) wrote:
> 
> > 2. Mechanism for separation of authpriv data 
> 
> Humm, so, I have my doubts that this really is desirable...
> 
> "because syslog did it this way too" doesn't sound like a really good
> reason for this.

No you are getting it wrong here.

It's not that syslog did it this way.

But syslog was configured explicitly this way and on purpose, if it were
logsys instead of syslog we'd still have the same configuration done by
the maintainers of the distro.

The point is that the authpriv target gets data from pam/login
applications and it is *normal* to have leaked password sin there.
So it should not be readable by anyone but root.
Or a leaked password suddenly becomes a privilege escalation issue
instead of just an annoyance.

>  I have my doubts that it really that much more
> desirable to have this split off. If we really split this off (which
> technically is easy to do), and nobody but root gets access to it, this
> means that it will be *really* hard to see this stuff, and since it's
> not that much data people will very likely never explicitly check for
> it.

It is supposed to be *really* hard because it is really sensitive.

>  I for one really would like to see these messages if I run
> "journalctl" as user "lennart", who is in "wheel". I should get to see
> these messages. But while I can see all other messages I wouldn't be
> able to see authpriv, and there'd be no easy way to make them visible to
> myself...

Too bad.

> Moreover, much of the information logged to authpriv is actually
> available in utmp/wtmp afaics, so the I do wonder why have this at
> all...

No passwords in there, unless you happen to have a password that is
incidentally also the name of a user.

> So I am not convinced this is really that nice a feature. Effectively
> this will have the effect that authpriv messages will end up being
> invisible to admins -- and the data is too precious to hide it away like
> this.

It's no different than what we have today, I have yet to see *anyone*
complaining and I work in Identity Management, authentication is my day
to day job.

> If we design the behaviour of these things we really need to focus on
> getting the interesting data to the admin, and not raise pointless
> stumbling blocks everywhere. And "syslog always did it that way" is a
> really bad reason on its own...

Please stop the 'syslog did it that way' strawman, the technology used
has nothing to do with the policy enforced.
It would have been supersimple to always pipe authpriv messages in
to /var/log/messages if people wanted to. Instead they got
in /var/log/secure because they are sensitive logs that are not supposed
to be casually looked at by less privileged users, even staff users.

> (I mean, maybe have this as an optional gimmick for the folks who
> understand the split and know where to look makes sense, but i don't
> think that this feature is really so superduper totally and utterly
> necessary as a default, as you suggest...)

It is superduper necessary by default, because you can't close the barn
*after* the sheep have escaped.

> > b. All utilities should always work sensibly with grep (this is not the
> >    case on F18 right now)
> 
> Hmm? How so? Bug?
> 
> > c. /var/log/messages written with a (syslog-formatted?) note pointing 
> >    to journalctl (maybe even showing the new time-based filtering?)
> 
> I'd much prefer adding /var/log/README instead, in order not to confuse
> tools which assume a properly formatted log file in /var/log/messages.

Good enough I guess.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York