[OLPC Security] P_READ_LOGS

[Jameson "Chema" Quinn]

For when we actually have bitfrost permissions in the interface, I propose
another simple bitfrost permission: P_READ_LOGS. This is easily doable with
groups and permissions. I think it would be safe and useful if it were: not
given by default; not compatible with P_NETWORK except through user
intervention; but given to any non-P_NETWORK activity which requested it. It
is true that some private data could leak into the logs, but in general the
amount would be negligible; in the exceptional cases (which would be bugs in
some activity), the lack of P_NETWORK would keep the data from spreading
anyway.

This would be useful for Develop, and also to remove Log and Analyze from
the list of activities which need the far-more-dangerous (and also
not-fully-consensed) "P_ROOT".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080810/059c8413/attachment.htm

[Benjamin M. Schwartz]

Jameson "Chema" Quinn wrote:
| For when we actually have bitfrost permissions in the interface, I propose
| another simple bitfrost permission: P_READ_LOGS.

I agree that reading logs is a valuable capability for Sugar to provide.
I don't see why any new Bitfrost permissions are required to enable it.

The easiest way to present logs, especially failure logs, is to make them
available through the standard Journal/Datastore interface. For example,
we have some agreement that when an Activity fails to launch, the failure
should appear as such in the Journal time-view, connected to an object
representing the log file for that failure. This log object has a "text"
type, and so can naturally be opened by any Activity that accepts this
type. No additional permissions are required. The user is responsible
for determining when to provide both sensitive data and P_NETWORK to the
same Activity.

Perhaps it would be helpful if you could give an example of a case in
which a P_READ_LOGS permission is the best solution, and better than
simply exposing the logs through the Journal.

- --Ben