On Tue, 09.10.12 15:41, Stephen John Smoogen (smooge@xxxxxxxxx) wrote: > On 9 October 2012 15:24, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > On Tue, 09.10.12 16:53, Simo Sorce (simo@xxxxxxxxxx) wrote: > > > If you want audit-like semantics with crashing if we cannot write, then > > use something else, not the journal. The journal is supposed to be > > robust and do the right thing so that you can leave it unnatteneded and > > whatever happens it didn't spill the disk or become unavailable. It's > > supposed to be "zero maintainance". > > So in those cases rsyslog would be required, but would be seen as a > post-install step. > > EG what you are looking at is building a GNOME-OS and for those sorts > of tablets, etc the journal is right for that. The other cases like at > a Hospital, trading firm or various .gov.XX then having rsyslog > installed with audit post would be the way to get the needed features. This is BS. The journal is for most folks, not just GNOME users. How many people actually enable "auditctl -f2"? There's probably not many except a few three letter agencies and similar folks. I don't really want to play in the three letter agency area. That doesn't mean I want to break things for them, I am just saying that the super-strict policies they want should not dictate how the system works for everybody else. As long as we make their setups possible (and yeah, installing rsyslog is not that hard), that's fine. But really, a webshop couldnt care less for such a mode. For most people reliability is more important than "auditctl -f2". Really, I have no intention to provide anything like "auditctl -f2" in journald. Not going to happen. People can install auditd/rsyslog for that. It's not my turf, I don't want those bugs. And anyway: it is really confused to believe that people care more for "auditcl -f2" than unfakable logs... I am not a security guy, but having logs where unprivileged users cannot insert undetectable fakes is much much much much much much more interesting to me thatn "auditctl -f2" like behaviour. And if that's any standard we never would have allowed syslog in the distro at all... To stress this: With the feature I am planning to propose for F19: - I just want to change what is installed/enabled by default - I do not want to break rsyslog or auditd or make them unavailable - I do plan to support the equivalent of most things syslog offers, but do not plan to provide *everything* syslog offers. One of these things is UDP syslog proto support. - I just want to provide something that is robust and secure and works for the vast majority of people without reconfiguration - something that brings a number of important improvements over syslog at a lower footprint - That works for server folks, embedded folks, desktop folks alike, but not necessarily all thinkable usecases of these uses. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
