On Wed, 2012-10-17 at 17:45 +0200, Lennart Poettering wrote: > On Wed, 17.10.12 10:44, Matthew Miller (mat...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
