<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Aug 1, 2008 at 4:07 PM, John Gilmore <span dir="ltr"><<a href="mailto:gnu@toad.com">gnu@toad.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">> Why does it matter that you cannot adjust the screen brightness from<br>
> the console using the special keys? You can adjust it from Sugar<br>
> without root access. The idea was to understand what limits we'd face<br>
> using the console for root access instead of a special terminal<br>
> activity. What are the Sugar/X Window actions that require root<br>
> access?<br>
<br>
</div>"It doesn't matter if you have to abandon Sugar to do system<br>
administration or to recover from a problem?"  Walter, I'm shocked; I<br>
would've expected you to be arguing on the other side: "Sugar should<br>
be the preferred environment."  That we shouldn't be kicking people<br>
out of Sugar, particularly when their system is fragile and in need of<br>
diagnosis, repair, or upgrade.  We should keep them in the environment<br>
they know and understand, where the Frame works, the controls work,<br>
the tabs work the same way, the keyboard keys all do the same things.<br>
<br>
It was hard for the Support Gang to explain to people how to become<br>
root so they could diagnose or fix something they reported as a<br>
problem (like a full filesystem, a USB key that didn't work, ...).<br>
OLPC was also changing the way you become root (su versus sudo) in<br>
different software releases, based on Fedora changes.  We hashed all<br>
this out in January, and the Terminal got a new "#" button at the top,<br>
which injects the right command to make you root.  There's no such<br>
button in the console.  If we push people back to the console, the<br>
support load increases.  It's easier to get them to run the Terminal<br>
applic...uh, activity, and press the root button, and type this<br>
command.  Also, in Terminal, cut and paste works to send us back<br>
diagnostic results via Browse.<br>
<br>
The owners of free software based machines also need the ability to<br>
inspect and revise the free software in those machines -- or it isn't<br>
free as in freedom.  Legally, OLPC can push that ability out to the<br>
very corners of the system (e.g. "You can't do that in Sugar.").  But<br>
morally and philosophically, we ought to be pulling it right into the<br>
heart of the system ("Of course you can, and it's so easy; here, let<br>
me show you!").<br></blockquote><div><br></div><div>I agree with everything said above. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Let's not lose sight of what's going on here.  The whole reason we are<br>
having this discussion at all is because of OLPC's "security" model<br>
(Bitfrost).  If the security model doesn't permit integrated,<br>
interactive root access that lets people diagnose, repair,<br>
investigate, and alter their systems, there's something wrong with the<br>
security model -- not something wrong with root access.<br></blockquote><div><br></div><div>And I wonder if it could really be so simple.  Is it possible that we could simply have a P_ROOT permission as well, or does that blow Bitfrost out of the water?  In a way I'd hope not, since the whole point is that the desire for root is requested/advertised, and therefore can (eventually) be denied; P_ROOT clearly wouldn't be granted  within the default permissions either, once we have them.</div>
<div><br></div><div>I write this assuming that this might not help matters at all...it could be too lenient.  But perhaps we could offer the P_ROOT only to activities which a) request it and b) are signed by some signing authority (could be us, could be a country, etc.), where the security section of the control panel offers a place to designate trusted signing authorities.  I'm no security guru, though, which I willingly admit!  Is anything I've mentioned worth even considering?</div>
<div><br></div><div>Clearly it's not "as secure", and there are ways that someone can instruct a kid to go to the CP, enter a new authority, install an evil app, etc.  But There's a tradeoff here much like the memory/speed tradeoff we battle with every day we hack at code...you can only improve some algorithms so much, and beyond that you have to choose what to optimize for.</div>
<div><br></div><div>- Eben</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
        John<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br>
</div></div></blockquote></div><br></div>