> > If we want to think about any next generation logging, I'm convinced,> > we need to support records, structured data and binary data; anything> > else is unlikely worth to change the current stuff.> > Any thoughts as to how one could allow N userspace agents to log to a> single shared buffer without one agent, if buggy or malicious,> spamming out all the other contents of the log? This is one of the> main reasons we maintain separate logs in Android today, and are> likely to continue doing so until we figure out how resolve the issue.

I have been working on some code to rate limit what clients can log tothe journal, with some nice tricks: the rate limiting is per-cgroup, sothat services can't flush out other services data so easily (assumingthey are in separate cgroups, which they are in a systemd world). Also,different rates apply to to messages with different priorities(i.e. we'll have a lower limit on debug messages, and allow moreimportant messages to be logged at a higher rate). And finally, we lookat the available disk space: the overall rate limits are increased ifthere's more free space, and lowered if there's less.

> Also, as I mentioned earlier, from a security standpoint it is highly> desirable to be able to restrict which records certain readers can> read. Convincing third party app developers to not log sensitive or> PII data remains a challenge -- providing the ability for filtered> read access allows some mitigation (app can retrieve it's own logs for> a bug report but can't sift through all logs looking for interesting> tidbits).

The journal splits up user data into sparate files and sets file accesspermissions to ensure that users can access their own data but nothingelse. However, when root wants to read all data it can, and the datawill be interleaved automatically.