From: Lennart Poettering <mzxreary@0pointer.de>
To: Brian Swetland <swetland@google.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>, Greg KH <gregkh@suse.de>,
Tim Bird <tim.bird@am.sony.com>,
linux-embedded <linux-embedded@vger.kernel.org>,
linux kernel <linux-kernel@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>, john stultz <johnstul@us.ibm.com>
Subject: Re: RFC: android logger feedback request
Date: Thu, 22 Dec 2011 14:40:17 +0100 [thread overview]
Message-ID: <20111222134017.GC7512@tango.0pointer.de> (raw)
In-Reply-To: <CANqkERCcciVxybh=66K5xxzzGmgw=fg0vwmcitWZ1y=DTxxtOA@mail.gmail.com>
On Wed, 21.12.11 20:22, Brian Swetland (swetland@google.com) wrote:
> > 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 to
the journal, with some nice tricks: the rate limiting is per-cgroup, so
that services can't flush out other services data so easily (assuming
they 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 more
important messages to be logged at a higher rate). And finally, we look
at the available disk space: the overall rate limits are increased if
there'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 access
permissions to ensure that users can access their own data but nothing
else. However, when root wants to read all data it can, and the data
will be interleaved automatically.
Lennart
--
Lennart Poettering - Red Hat, Inc.
next prev parent reply other threads:[~2011-12-22 13:40 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-21 22:59 RFC: android logger feedback request Tim Bird
2011-12-21 23:19 ` Greg KH
2011-12-22 0:18 ` john stultz
2011-12-22 0:27 ` Greg KH
2011-12-22 0:47 ` john stultz
2011-12-22 1:09 ` john stultz
2011-12-22 0:42 ` Tim Bird
2011-12-22 0:49 ` john stultz
2011-12-22 1:00 ` john stultz
2011-12-22 0:36 ` Tim Bird
2011-12-22 0:51 ` Greg KH
2011-12-22 1:32 ` Tim Bird
2011-12-22 1:47 ` Greg KH
2011-12-22 2:12 ` Tim Bird
2011-12-22 3:44 ` Kay Sievers
2011-12-22 3:45 ` Greg KH
2011-12-22 3:47 ` Greg KH
2011-12-22 4:12 ` Kay Sievers
2011-12-22 4:22 ` Brian Swetland
2011-12-22 4:43 ` Kay Sievers
2011-12-22 4:47 ` david
2011-12-22 4:58 ` Brian Swetland
2011-12-22 5:07 ` david
2011-12-22 5:21 ` david
2011-12-22 13:40 ` Lennart Poettering [this message]
2011-12-22 4:49 ` david
2011-12-22 2:34 ` Kay Sievers
2011-12-22 1:20 ` NeilBrown
2011-12-22 1:49 ` Greg KH
2011-12-22 2:14 ` Tim Bird
2011-12-22 2:34 ` Brian Swetland
2011-12-22 3:49 ` Greg KH
2011-12-22 4:36 ` Kay Sievers
2011-12-22 5:01 ` david
2011-12-22 4:52 ` david
2011-12-22 5:06 ` Brian Swetland
2011-12-22 5:14 ` david
2011-12-22 5:25 ` Brian Swetland
2011-12-22 6:09 ` Greg KH
2011-12-23 15:22 ` Alan Cox
2011-12-23 16:29 ` Greg KH
2011-12-22 7:05 ` NeilBrown
2012-01-06 20:56 ` Tim Bird
2012-01-06 21:20 ` Greg KH
2012-01-06 22:41 ` Tim Bird
2012-01-06 23:17 ` Greg KH
2012-01-06 23:35 ` Greg KH
2011-12-22 14:59 ` Arnd Bergmann
2011-12-22 15:13 ` Kay Sievers
2011-12-22 4:42 ` david
2011-12-22 0:59 ` David Brown
2011-12-29 0:39 ` Andrew Morton
2012-01-04 15:34 ` Geunsik Lim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111222134017.GC7512@tango.0pointer.de \
--to=mzxreary@0pointer.de \
--cc=arnd@arndb.de \
--cc=gregkh@suse.de \
--cc=johnstul@us.ibm.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=swetland@google.com \
--cc=tim.bird@am.sony.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).