On Fri, Aug 1, 2008 at 4:07 PM, John Gilmore <[EMAIL PROTECTED]> wrote:
> > Why does it matter that you cannot adjust the screen brightness from > > the console using the special keys? You can adjust it from Sugar > > without root access. The idea was to understand what limits we'd face > > using the console for root access instead of a special terminal > > activity. What are the Sugar/X Window actions that require root > > access? > > "It doesn't matter if you have to abandon Sugar to do system > administration or to recover from a problem?" Walter, I'm shocked; I > would've expected you to be arguing on the other side: "Sugar should > be the preferred environment." That we shouldn't be kicking people > out of Sugar, particularly when their system is fragile and in need of > diagnosis, repair, or upgrade. We should keep them in the environment > they know and understand, where the Frame works, the controls work, > the tabs work the same way, the keyboard keys all do the same things. > > It was hard for the Support Gang to explain to people how to become > root so they could diagnose or fix something they reported as a > problem (like a full filesystem, a USB key that didn't work, ...). > OLPC was also changing the way you become root (su versus sudo) in > different software releases, based on Fedora changes. We hashed all > this out in January, and the Terminal got a new "#" button at the top, > which injects the right command to make you root. There's no such > button in the console. If we push people back to the console, the > support load increases. It's easier to get them to run the Terminal > applic...uh, activity, and press the root button, and type this > command. Also, in Terminal, cut and paste works to send us back > diagnostic results via Browse. > > The owners of free software based machines also need the ability to > inspect and revise the free software in those machines -- or it isn't > free as in freedom. Legally, OLPC can push that ability out to the > very corners of the system (e.g. "You can't do that in Sugar."). But > morally and philosophically, we ought to be pulling it right into the > heart of the system ("Of course you can, and it's so easy; here, let > me show you!"). > I agree with everything said above. > > Let's not lose sight of what's going on here. The whole reason we are > having this discussion at all is because of OLPC's "security" model > (Bitfrost). If the security model doesn't permit integrated, > interactive root access that lets people diagnose, repair, > investigate, and alter their systems, there's something wrong with the > security model -- not something wrong with root access. > 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. 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? 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. - Eben > > John > > > > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel >
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel