Rainbow
On Wed, 2010-07-07 at 01:18 -0400, Michael Stone wrote: > > XO and SoaS distributions are configured for sudo with no password. > > Yes. However, Uruguay does not maintain this configuration choice. I'm very sorry about this. > > Rainbow has been bit-rotting for the past 2 years > > Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still > received no independent testing despite repeated calls for same. Raul and I would have liked to resurrect Rainbow in time for F11-0.84, and then for F11-0.88. We asked a couple of times about the current packaging status and what patches still need to be applied in Sugar, but it seemed that there was still too much integration work to be done. > > and nobody volunteered to work on it. > > If you check the dates carefully, you'll find that most of my recent work on > rainbow and rainbow/sugar integration has occurred while I was on vacation > from > my real job. So please do count that as "volunteer hours". Don't get me wrong, your volunteer work to enhance Rainbow is much appreciated, but it is not by itself sufficient to get Rainbow to work again with Sugar. There seems to be the need for someone who'd be willing to do the missing integration work. People with both Sugar and Rainbow expertise aren't that common. > Sure. And if, by some miracle, Sugar ever becomes *worth* attacking [1], then > we will all rue the day when we had the opportunity to make it safe and chose > not to. I wouldn't worry very much: the attack surface of Sugar from the public Internet is very small: basically, just xulrunner. The LAN of an elementary school is relatively free of advanced crackers. This leaves out only unusual Sugar instances that are being used from home networks connected directly to the Internet. The worst attack vector I can think of would be a malicious activity. I think this is pretty much the same threat of malicious Firefox plugins, and it is being taken care of exactly in the same way. If it becomes Perhaps I'm not being paranoid enough... but anyway, if the situation worsens, we could always restore Rainbow and/or check gpg signatures on installation, like most Linux distros do. > > A non-privileged account can already effectively do anything that a spammer > > would like to do. > > And when will you be shipping my prctl(PR_DISABLENETWORK) kernel patch? > > (Or have you a better approach?) I thought the review got swamped on lkml a long time ago? Or maybe I was dropped off the cc list... Last thing I know, there was disagreement about what the correct approach was and some linux hackers derailed the thread by invoking the stackable LSM bullshit. What matters the most is that nobody thought that the scenario that your patch was trying to address wasn't an interesting one. You might have a chance to get *some* version of your patch approved if you aggressively reply to the nonsense reviews asking the reviewer: - how would you do it instead? - does your alternative effectively address my use-case? - you and X sent conflicting feedback, please sort it out among yourselves and let me know which approach is preferred - who is the authoritative maintainer to ack a patch like this? In a case like yours, the technical side of getting the patch right is very easy compared to mediating among conflicting design goals. > I am still much more satisfied with the approach taken by 0install. [2] 0install is a huge leap forward compared to the crap xo bundle format, but still too much prototypal to cover half of our requirements. The biggest flaw is that there's no well-defined build system to obtain binaries from sources, so activities authors would have to setup multiple environments and build manually for all the architectures we intend to support. When you add a new architecture, it takes months or years before most activities become available for it. I've been advocating a proper build cluster for years. Now that OLPC is working on an ARM-based platform, it will be clear to anyone why it was needed. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help with permissions under Rainbow sought
George Hunt wrote: > I had looked for an input mechanism to Rainbow's CONSTANT_RAINBOW_UID > without success. So thanks for your pointer. Where did you look? (I'd like to go fix it...) > I'm curious to know why you think using a constant UID is undesireable. Making things constant-uid in the sugar-0.82 + rainbow-0.7.* world removes all isolation between instances of the activity. > At this point I'm looking for ways to simplify the next stages of debugging my > program. > > My thinking is as follows: If I can get permissions off the table as a > source of failure, while I deal with all the other problems I haven't > foreseen, I can come back and tighten up security when my code is more > solid. Your reasoning seems fine to me. (One word of caution, though: rainbow will probably not respond well to seeing a single activity bundle_id switch between the constant-uid and the (default) fresh-uid setting. Therefore, you should either use a fresh bundle_id when you switch or you should clean out rainbow's filesystem state in /etc/passwd, /etc/group, and /home/olpc/isolation/1/.) Regards, Michael P.S. - I really like ipython, so I'm excited to see your activity. Also, if you like ipython, check out bpython. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help with permissions under Rainbow sought
On 18.04.2010, at 17:10, Michael Stone wrote: > > Bert Freudenberg wrote: >> On 18.04.2010, at 14:10, Sascha Silbe wrote: >>> On Sat, Apr 17, 2010 at 09:26:23PM -0400, George Hunt wrote: >>> >>>> Rainbow changes UID for every invocation [...] >>> >>> Yes, that's the default behaviour. Rainbow can be instructed to use a >>> constant UID (Browse does); according to the OLPC wiki [1] you'd need to >>> add a >>> file activity/permissions.info, containing "constant-uid" on a single line. >>> >>> This is the least preferable solution, though. >>>> Apparently the create mask rainbow uses is 755 and group members do not >>>> have write access. >>> >>> It's not Rainbow that decides this. >> >> But arguably Rainbow could set a better default, no? Making files >> group-writable? > > Rainbow actually calls os.umask(0) here: > > http://dev.laptop.org/git/security/tree/rainbow/rainbow/inject.py#n263 > > However, it's entirely possible that some other logic in your program is > setting umask(022) or is creating files with an explicitly specified mode. > (You > may recall that xulrunner's behavior here was the reason why constant-uid was > introduced.) Well, I remember having to put the "umask 0002" call in the Etoys startup script a long time ago. It's still there, but unconditionally. Hence my next question ... >> Hmm, how do I test if Rainbow is enabled, in a shell script, again? > > If you mean "is sugar going to launch the next activity it launches under > rainbow?", then test for the presence of /etc/olpc-security, e.g. with > > if [ -f /etc/olpc-security ]; then ... fi > > If you mean "is my script currently running under rainbow?", then I don't > have a > perfect answer for you this instant. > (A good but imperfect answer is to test whether whether getuid() > 1 and > getgid() > 1, e.g. by parsing the output of the "id" command.) > Regards, > > Michael I meant the latter. Guess I won't worry too much, since most distros nowadays use per-user groups anyway. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help with permissions under Rainbow sought
Bert Freudenberg wrote: >On 18.04.2010, at 14:10, Sascha Silbe wrote: >> On Sat, Apr 17, 2010 at 09:26:23PM -0400, George Hunt wrote: >> >>> Rainbow changes UID for every invocation [...] >> >> Yes, that's the default behaviour. Rainbow can be instructed to use a >> constant UID (Browse does); according to the OLPC wiki [1] you'd need to add >> a >> file activity/permissions.info, containing "constant-uid" on a single line. >> >> This is the least preferable solution, though. >> >>> Apparently the create mask rainbow uses is 755 and group members do not >>> have write access. >> >> It's not Rainbow that decides this. > >But arguably Rainbow could set a better default, no? Making files >group-writable? Rainbow actually calls os.umask(0) here: http://dev.laptop.org/git/security/tree/rainbow/rainbow/inject.py#n263 However, it's entirely possible that some other logic in your program is setting umask(022) or is creating files with an explicitly specified mode. (You may recall that xulrunner's behavior here was the reason why constant-uid was introduced.) >Hmm, how do I test if Rainbow is enabled, in a shell script, again? If you mean "is sugar going to launch the next activity it launches under rainbow?", then test for the presence of /etc/olpc-security, e.g. with if [ -f /etc/olpc-security ]; then ... fi If you mean "is my script currently running under rainbow?", then I don't have a perfect answer for you this instant. (A good but imperfect answer is to test whether whether getuid() > 1 and getgid() > 1, e.g. by parsing the output of the "id" command.) Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help with permissions under Rainbow sought
Sascha, I'll plan to put the history in the Journal -- seems like a good idea. I had looked for an input mechanism to Rainbow's CONSTANT_RAINBOW_UID without success. So thanks for your pointer. I'm curious to know why you think using a constant UID is undesireable. At this point I'm looking for ways to simplify the next stages of debugging my program. My thinking is as follows: If I can get permissions off the table as a source of failure, while I deal with all the other problems I haven't foreseen, I can come back and tighten up security when my code is more solid. With much appreciation for your help, George On Sun, Apr 18, 2010 at 8:10 AM, Sascha Silbe < sascha-ml-ui-sugar-olpc-de...@silbe.org> wrote: > On Sat, Apr 17, 2010 at 09:26:23PM -0400, George Hunt wrote: > > I am using an ipython console application which writes a history file to >> the home directory (I changed the HOME environment to SUGAR_ROOT/data). >> > Have you considered saving the history as part of the data store entry > instead? That way your activity wouldn't mix histories from separate > sessions (i.e. when debugging several different programs). > > Rainbow changes UID for every invocation [...] >> > Yes, that's the default behaviour. Rainbow can be instructed to use a > constant UID (Browse does); according to the OLPC wiki [1] you'd need to add > a file activity/permissions.info, containing "constant-uid" on a single > line. > This is the least preferable solution, though. > > > Apparently the create mask rainbow uses is 755 and group members do not >> have write access. >> > It's not Rainbow that decides this. Permissions of newly created file > system entries (i.e. files and directories) are determined by the umask (see > e.g. "man 2 umask"). You can either widen the permissions after creation > using chmod() (see "pydoc os.chmod") or tweak the umask (see "pydoc > os.umask"); since the latter affects _all_ created files I would recommend > the chmod() (you could save+restore the umask, but it's prone to race > conditions). > > > [1] http://wiki.laptop.org/go/Activity_bundles#activity.2Fpermissions.info > > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJLyvayAAoJELpz82VMF3Da4IoIAI+HUTUnCJWOrz0kk4reyDmh > GaBNXbG/DbMSRf0EEKiXCVABzQahgKUFg7PKiIZY5xl+Qt5esPQ50KDlsPUZYG+K > 972H9/VNRo+kTOZ9JuYGDzKsexwowparXLH7QFL9wZNy/+5eA2vy/qH6kKlKrarZ > Qki9Comwxh6aRKqXhlrTQn5/IXA0FoXySjx37T8jW+hJTRe05QfKIJrsUVTks/t7 > BnviPWfrJHip2LIDmsChrVDPsibUKBvC7hGV+iEsbCUSQKpt+Nf97jWw8eWL+pbx > tmUfNAuuI9CGpgoFsrJjZ3PUR/fvrcDJb9CvXEDz0+VorZuRiSN7tE2883yIXzY= > =X+wE > -END PGP SIGNATURE- > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help with permissions under Rainbow sought
On 18.04.2010, at 14:10, Sascha Silbe wrote: > > On Sat, Apr 17, 2010 at 09:26:23PM -0400, George Hunt wrote: > >> I am using an ipython console application which writes a history file to the >> home directory (I changed the HOME environment to SUGAR_ROOT/data). > Have you considered saving the history as part of the data store entry > instead? That way your activity wouldn't mix histories from separate sessions > (i.e. when debugging several different programs). > >> Rainbow changes UID for every invocation [...] > Yes, that's the default behaviour. Rainbow can be instructed to use a > constant UID (Browse does); according to the OLPC wiki [1] you'd need to add > a file activity/permissions.info, containing "constant-uid" on a single line. > This is the least preferable solution, though. > >> Apparently the create mask rainbow uses is 755 and group members do not have >> write access. > It's not Rainbow that decides this. But arguably Rainbow could set a better default, no? Making files group-writable? Have to admit I forgot how the sticky bits on the data dir affects this though. > Permissions of newly created file system entries (i.e. files and directories) > are determined by the umask (see e.g. "man 2 umask"). You can either widen > the permissions after creation using chmod() (see "pydoc os.chmod") or tweak > the umask (see "pydoc os.umask"); since the latter affects _all_ created > files I would recommend the chmod() (you could save+restore the umask, but > it's prone to race conditions). When running in Rainbow, setting "umask 0002" shouldn't hurt in general. Hmm, how do I test if Rainbow is enabled, in a shell script, again? - Bert - > > [1] http://wiki.laptop.org/go/Activity_bundles#activity.2Fpermissions.info > > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/___ > 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
Re: Help with permissions under Rainbow sought
On Sat, Apr 17, 2010 at 09:26:23PM -0400, George Hunt wrote: I am using an ipython console application which writes a history file to the home directory (I changed the HOME environment to SUGAR_ROOT/data). Have you considered saving the history as part of the data store entry instead? That way your activity wouldn't mix histories from separate sessions (i.e. when debugging several different programs). Rainbow changes UID for every invocation [...] Yes, that's the default behaviour. Rainbow can be instructed to use a constant UID (Browse does); according to the OLPC wiki [1] you'd need to add a file activity/permissions.info, containing "constant-uid" on a single line. This is the least preferable solution, though. Apparently the create mask rainbow uses is 755 and group members do not have write access. It's not Rainbow that decides this. Permissions of newly created file system entries (i.e. files and directories) are determined by the umask (see e.g. "man 2 umask"). You can either widen the permissions after creation using chmod() (see "pydoc os.chmod") or tweak the umask (see "pydoc os.umask"); since the latter affects _all_ created files I would recommend the chmod() (you could save+restore the umask, but it's prone to race conditions). [1] http://wiki.laptop.org/go/Activity_bundles#activity.2Fpermissions.info CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Help with permissions under Rainbow sought
Hi all, I've been trying, in the last few days, to put the finishing touches on the PyDebug activity I have been developing. I am using an ipython console application which writes a history file to the home directory (I changed the HOME environment to SUGAR_ROOT/data). Rainbow changes UID for every invocation of the debugger so therefore the ability of ipython to update its history file would have to be based upon GID which is constant from one invocation to the next. Apparently the create mask rainbow uses is 755 and group members do not have write access. I came upon the strategy of having my program update the write permissions for group after every file creation so that full access would be available at the next invocation. But then I discovered that during execution, python creates the *.pyc files. If the process blows up before I have a chance to rewrite permissions, I will not be able to change the program and continue debugging. The only two solutions i've been able to come up with is to use supper user and the Terminal Activity to: 1. add 'org.laptop.PyDebug' to the list of programs for which rainbow is disabled in 'activityfactoryr' or 2. disable bitfrost entirely by renameing /etc/old-security. #1 seems much preferable, for XO1.5 and f11 for XO1.0. But it's kludgy for earlier builds. I don't know whether there are deployments that disable superuser in Terminal Application, which would make a patch impossible. Is there a solution I"m missing? George ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Getting Rainbow to read new permissions.info
On Thu, Jan 14, 2010 at 06:51:34PM +0100, Martin Langhoff wrote: > - on systems where earlier WikipediaES versions were started, Rainbow > seems to remember the old "any uid" mode, and ignores the request for > a persistent uid. Interesting. Are you starting the activity with an existing journal entry for it? e.g. a coloured icon in the activity ring shows this, and it can be avoided by right-clicking on the icon and choosing the monochrome Start. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Getting Rainbow to read new permissions.info
Working with the Rainbow we shipped in 8.2.1, and looking at http://dev.laptop.org/ticket/8814#comment:19 Briefly, Wikipedia-xo packages have been seeing warnings from the xulrunner engine (and some minor bugs) because they should use "persistent-uid" in permissions.info... and they don't. Now, if I prepare a new WikipediaES-11.xo release that does contain the right permissions.info file, I see two different behaviours... - on systems where WikipediaES was never used before, it does the right thing - on systems where earlier WikipediaES versions were started, Rainbow seems to remember the old "any uid" mode, and ignores the request for a persistent uid. I am looking around the Rainbouw source files but I haven't seen anything obvious yet -- unless I am making a mistake in my process, it sounds like a bug. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ANN: rainbow-0.8.6 release.
On 22.12.2009, at 06:06, Michael Stone wrote: > > Friends, > > I am pleased to announce the release of rainbow-0.8.6. Rainbow implements > portions of the isolation shell described in the Bitfrost threat model and > security architecture. > > The key differences between this release and its predecessor include support > for garbage collection of uids, ui sugar for resuming uids, bug fixes to the > resume logic, and a simplified singly-linked list library. > > This release was made possible by encouragement and suggestions from Sascha > Silbe, Bernie Innocenti, and Benjamin Mako Hill. It has been (minimally) > tested > on Debian Sid, Ubuntu Karmic, and Fedora Rawhide and has been packaged in > Fedora Rawhide for your convenience. > > Interesting links for this release include: > > git:git://dev.laptop.org/users/mstone/security > tar: > http://dev.laptop.org/~mstone/releases/SOURCES/rainbow-0.8.6.tar.bz2 > browse: > http://dev.laptop.org/git/users/mstone/security/tree/?id=rainbow-0.8.6 > setup: http://wiki.laptop.org/go/Rainbow/Installation_Instructions > tests: http://wiki.laptop.org/go/Rainbow/Testing > > The shortlog from rainbow-0.8.5..rainbow-0.8.6 is: > > Bernie Innocenti (1): > Capture XAUTHORITY. > > Michael Stone (19): > Remove unused flexibility from the spool option parsing code. > First pass at updated rainbow-gc. > Clean up group membership. > Protect sticky uids from garbage collection. > Clean up some per-uid Xephyr data. > Improve spool detection checks. > Install rainbow-gc. > Add some logging to rainbow-gc. > Make xephyr usage resumable. > Teach rainbow to resume uids with more auxiliary groups. > Add a simple resume subcommand. > Add INIT() and COPY() operators from dnshash. > Add a novel singly-linked list implementation. > Add test_endgrent script. > Simplify list traversal logic. > Fix Karmic sudo segfault. > Tweak warnings and link flags. > Set default spool location in rainbow-gc. > rainbow-0.8.6. > > Kind regards, > > Michael Yay! - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
ANN: rainbow-0.8.6 release.
Friends, I am pleased to announce the release of rainbow-0.8.6. Rainbow implements portions of the isolation shell described in the Bitfrost threat model and security architecture. The key differences between this release and its predecessor include support for garbage collection of uids, ui sugar for resuming uids, bug fixes to the resume logic, and a simplified singly-linked list library. This release was made possible by encouragement and suggestions from Sascha Silbe, Bernie Innocenti, and Benjamin Mako Hill. It has been (minimally) tested on Debian Sid, Ubuntu Karmic, and Fedora Rawhide and has been packaged in Fedora Rawhide for your convenience. Interesting links for this release include: git:git://dev.laptop.org/users/mstone/security tar: http://dev.laptop.org/~mstone/releases/SOURCES/rainbow-0.8.6.tar.bz2 browse: http://dev.laptop.org/git/users/mstone/security/tree/?id=rainbow-0.8.6 setup: http://wiki.laptop.org/go/Rainbow/Installation_Instructions tests: http://wiki.laptop.org/go/Rainbow/Testing The shortlog from rainbow-0.8.5..rainbow-0.8.6 is: Bernie Innocenti (1): Capture XAUTHORITY. Michael Stone (19): Remove unused flexibility from the spool option parsing code. First pass at updated rainbow-gc. Clean up group membership. Protect sticky uids from garbage collection. Clean up some per-uid Xephyr data. Improve spool detection checks. Install rainbow-gc. Add some logging to rainbow-gc. Make xephyr usage resumable. Teach rainbow to resume uids with more auxiliary groups. Add a simple resume subcommand. Add INIT() and COPY() operators from dnshash. Add a novel singly-linked list implementation. Add test_endgrent script. Simplify list traversal logic. Fix Karmic sudo segfault. Tweak warnings and link flags. Set default spool location in rainbow-gc. rainbow-0.8.6. Kind regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] ANN: rainbow-0.8.5 release.
Bringing these very useful notes back to the list. Below, Michael outlines steps-to-integrate... On Sun, Nov 29, 2009 at 2:44 PM, Michael Stone wrote: >> If there was someone interested in >> re-integrating rainbow into the stack, beyond the obvious of packaging >> the latest release, what does the job look like? >> >> - an init script needs to be enabled? > > No init scripts needed (yet) -- this is a pure exec-chain. > >> - nss config > > Yup, but that's a two-line sed script. (Maybe guarded by a one-line grep). > >> - enabling something in sugar / reverting some patches? > > See the "sugar+rainbow" section at the bottom of > http://wiki.laptop.org/go/Rainbow/Installation_Instructions. I haven't > tested these instructions since the cited sugar patches were merged a > few months back (though some six months after they were written!) so > they may have bitrotted a little bit. However, they shouldn't be too > hard to fix up. I expect that the biggest change will be the > additional one-line patch will be needed to add the "-o network" > option but that shouldn't be a big deal. > >> - working through Sugar activities that may not be doing things in >> rainbow-compatible ways? > > Yup, though this should be less effort than last time around, both due > to activities being cast from a different mold this year and due to > rainbow imposing fewer requirements than before. > >> - other steps before it`s in a reasonable-enough shape to work? > > Mostly depends on how you want to deal with the configuration changes > that are necessary to permit isolated activities to use D-Bus, GConf, > etc. After that, getting to the point where most activities launch is > fairly straightforward. Testing and fixing them is a bit more work but > we have a good database of what has broken in the past. Finally, we > would need to either revive the rainbow-gc garbage collection script > (not too hard; just haven't needed it yet myself) or to teach Sugar to > keep track of containers and to pass the "-r " option when it > wants to resume the activity contained by . > > Questions? m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
ANN: rainbow-0.8.5 release.
Friends,
I am pleased to announce the release of rainbow-0.8.5. Rainbow implements
portions of the isolation shell described in the Bitfrost threat model and
security architecture.
The key differences between this release and its predecessor are bug fixes,
preliminary support for network isolation, and a better rainbow-sugarize
plugin.
This release was made possible by encouragement from Fabian Affolter, Luke
Faraone, Martin Langhoff, and my friends at sandboxing.org.
Interesting links for this release include:
git:git://dev.laptop.org/users/mstone/security
tar:http://dev.laptop.org/~mstone/releases/SOURCES/rainbow-0.8.5.tar.bz2
browse:
http://dev.laptop.org/git/users/mstone/security/tree/?id=rainbow-0.8.5
setup: http://wiki.laptop.org/go/Rainbow/Installation_Instructions
tests: http://wiki.laptop.org/go/Rainbow/Testing
The shortlog from rainbow-0.8.4..rainbow-0.8.5 is:
Michael Stone (10):
Correct a logging statement.
Make rainbow-sugarize set up /{data,instance,tmp}.
Temporarily disable $XAUTHORITY processing in rainbow-sugarize.
Drop config file management from rainbow-sugarize.
Add a network option enabling unshare(CLONE_NEWNET).
Make nss-rainbow's return and error codes more accurate.
Correctly calculate number of members of a struct group.
Make getpwent() resume on the correct uid.
Grant network access to rainbow-easy programs.
rainbow-0.8.5.
Finally, please note that:
* rainbow-run now calls unshare(CLONE_NEWNET) unless the "-o network"
command-line argument is given. This argument is given by the
"rainbow-easy" helper since X11 clients are unable start without it.
* rainbow's nss module must still be activated in /etc/nsswitch.conf in order
for the software to function correctly. See the setup instructions linked
to above for details.
Kind regards,
Michael
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
ANN: rainbow-0.8.4 release.
Folks,
I've put together a new rainbow release, rainbow-0.8.4,
http://wiki.laptop.org/go/Rainbow
http://dev.laptop.org/~mstone/releases/SOURCES/rainbow-0.8.4.tar.bz2
with three tasty new features which I think you might enjoy.
New Features
1) support for reusing existing containers (uids)
(this should be particularly useful for sugar since it gives activities
persistent $HOME dirs where they may save their configuration.)
rainbow-run option: "-r 10001"
2) better data-sharing functionality through isolated "topic dirs"
(these are just groups and matching setgid group-writable directories
like "movies" or "banking" which have both owning uids and isolated uids
as their members -- think of sugar's per-bundle "$SAR/data" dirs)
rainbow-run option: "-i movies -i banking"
3) experimental support for generating nested Xephyr X servers
(mainly as a thought experiment)
rainbow-run option: "-o xephyr"
Quality
---
This code is NOT KNOWN TO BE CORRECT [secure]. It just passes my most primitive
smoke tests. Therefore, please try it out and send me bug reports so that it
can one day become production-quality or, if you're feeling adventurous, do
some code-review (patch-level, module-level, whatever...) or test-case
submission (automated or otherwise) yourself so that we can all laugh at my
silly mistakes now instead of crying over them in the future. (Obviously, I'd
be happy to review patches that you send to me as well.)
code: http://dev.laptop.org/git/users/mstone/security
tests: mainly the example scripts on the wiki page
Compatibility
-
This code is definitely not backwards compatible with previous APIs.
The biggest compatibility-breaking changes that I presently know about are:
a) I no longer generate $HOME/{data,instance,tmp} since there's plugin-like
functionality which can be used to do so when it's necessary and because:
* "data" is subsumed by the "topic dirs" described above.
* "instance" was a design mistake which is finally fixed by support for
writable persistent $HOME dirs and container reuse
* "tmp" was removed because I'm not sure how to implement it correctly
and because $TMPDIR, /tmp, and /var/tmp are good enough for me at the
moment.
At any rate, I /think/ that Sugar activities which now require these dirs
can be made to work without modification with a little bit of
plugin-development by me and the Sugar team; my goal at the moment is to
make sure that rainbow is generally useful and that new activities can be
written against a less-contrived API.
b) I'm sure that I've broken rainbow's "options" support for things like
strace, constant-uid, and serial usage. (This should be easy to fix; I
just decided that I want to ship the rest of this code "sooner" rather
than "later".)
Regards from Santorini,
Michael
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Rainbow, olpc-update, and olpcrd.
> Peter, > > Your remark does not contain any specific questions so it's a little > hard for me to give you a coherent update. Instead, I'll make some > general remarks in the hope that they will elicit further questions. Sorry, there were no real questions, but its more about the status of where it stands within Fedora rawhide. The current understanding is what's documented at this link. If you have more to provide that would be great (I was already aware of rainbow and the PID changes but didn't put details in as I don't know alot about early boot processes). https://fedoraproject.org/wiki/OLPC/Packages_for_F11 > 1. As has been recently pointed out, Rainbow is not currently in use > on any Sugar platform later than sugar-*-0.84 (i.e. OLPC's 8.2.*). > However, some have wondered whether it might make a reappearance in > sugar-*-0.86. To speed this outcome, I have prepared new versions of > rainbow (0.8.*) which are easy to install and test on many different > platforms. See I presume you mean later than 0.8.2? > http://wiki.laptop.org/go/Rainbow > > for current status information. > (I await further rainbow-0.8.* questions, comments, concerns, and > test results with particular interest.) I believe the major concerns around about the changes to init to run it as PID 1 and what changes can be made for Fedora mainline acceptance. I have no idea about the pros and cons of this hence the generic query. > 2. There is little change in the state of olpcrd and olpc-update. > Daniel Drake did some nice work in February to make the toolchain > support OFW-hosted key overlays and, so far as I know, is happily > serving Paraguay-signed leases and software updates over Paraguay's > test schools' wifi network. > (Dan -- could you please update > http://wiki.laptop.org/go/Security > > with links to a description of how you've deployed these > technologies?) > > (Peter -- Did you have some specific question about the technology or > about its inclusion [or lack thereof] in Fedora?) About its inclusion in Fedora. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Rainbow, olpc-update, and olpcrd.
> The main and probably most major issues outstanding are the > kernel/boot process - so > kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection > of stuff of which I have no real idea about. Updates? Peter, Your remark does not contain any specific questions so it's a little hard for me to give you a coherent update. Instead, I'll make some general remarks in the hope that they will elicit further questions. 1. As has been recently pointed out, Rainbow is not currently in use on any Sugar platform later than sugar-*-0.84 (i.e. OLPC's 8.2.*). However, some have wondered whether it might make a reappearance in sugar-*-0.86. To speed this outcome, I have prepared new versions of rainbow (0.8.*) which are easy to install and test on many different platforms. See http://wiki.laptop.org/go/Rainbow for current status information. (I await further rainbow-0.8.* questions, comments, concerns, and test results with particular interest.) 2. There is little change in the state of olpcrd and olpc-update. Daniel Drake did some nice work in February to make the toolchain support OFW-hosted key overlays and, so far as I know, is happily serving Paraguay-signed leases and software updates over Paraguay's test schools' wifi network. (Dan -- could you please update http://wiki.laptop.org/go/Security with links to a description of how you've deployed these technologies?) (Peter -- Did you have some specific question about the technology or about its inclusion [or lack thereof] in Fedora?) Regards from Athens, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Mon, Mar 02, 2009 at 02:08:38PM +0100, Peter Robinson wrote: >The changes to sugar might be minimal but the changes to the >underlying OS are not so simple. > >From my (which is very basic) understanding there is patches to at >least the kernel, initscripts, upstart and telepathy and possibly dbus >to support rainbow. Peter, You're confusing rainbow (the activity isolation component of Bitfrost) with many other components including olpc-update, olpcrd, OFW, and hardware support. Please read http://wiki.laptop.org/go/Rainbow and let me know if you're still concerned about what's required to use Rainbow or about how I intend to make it easier still adopt. >This makes it very hard to use it in a standard distro environment especially >where Fedora (for example) already uses SELinux to implement some of the >features of rainbow. I can see from reading the selinux-policy sources that lots of hard work has gone into confining all sorts of system services. Tell me, though -- what SELinux policy prevents a typical Abiword or Evince process, run by me from my desktop, from writing to my ~/.bashrc? Moreover, even supposing this policy exists, is it used by default on any Fedora spins, let alone on the main Fedora livecds? Rainbow has offered this safeguard, on by default on XOs, for over a year. (NB: Perhaps, we would be better served by spending our time wondering how the two technologies can complement one another, each sustaining guarantees that are too expensive [in complexity] for the other to maintain?) Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
>> To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because >> it seemed like an interesting challenge. I'm not clear why Sugar needs more >> protection from rogue activities than a normal desktop environment has from >> rogue applications. >> Reinventing the desktop as a constructivist learning environment is a big >> enough task for one development team / community to swallow. Reinventing >> security is an altogether separate cause. >> That said, Rainbow exists, so we don't need to do anything to remove it. So >> long as people step up to maintain it and help activity developers fix the >> issues they run into. > > Yeah, that's a very important point. I think we already know the kind > of issues we can expect to find and maybe should think twice before > throwing out all that knowledge. > > I don't see Rainbow in Sugar as too controversial, because: > > - the modifications needed to the Sugar platform are minimal, The changes to sugar might be minimal but the changes to the underlying OS are not so simple. >From my (which is very basic) understanding there is patches to at least the kernel, initscripts, upstart and telepathy and possibly dbus to support rainbow. This makes it very hard to use it in a standard distro environment especially where Fedora (for example) already uses SELinux to implement some of the features of rainbow. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 10:09:26AM -0800, Carol Farlow Lerche wrote: > My post was a request to the most knowledgeable person, Michael to do the > service of taking the time to write a document that clearly lays out > >. the purpose (not in security speak but in terms of the benefits it brings >to end users), > >. the relevance of APIs versus packaging elements versus choices by the >sugar shell/infrastructure developers, > >. things that the activity developers can and can't do (given that I, at >least, hope that new developers will participate, who have preconceptions >from other environments), > >. things that are hoped for in future development (well delimited from things >that are there now.) > >Good documentation is hard, and wiki pages are only good documentation if >the wiki is maintained with great discipline (which I fear is not the case >at w.l.o). But for a subtle and complex feature such as Rainbow, good >documentation would be a motivator for use both within and outside the sugar >community. Carol, I can't promise that I've reached "clearly lays out" yet, but I /have/ worked a bit on unifying the Rainbow wiki page: http://wiki.laptop.org/go/Rainbow and I think that I could now use some more feedback about which parts are working for you and which parts aren't. Thanks, Michael P.S. - Other sugar folks might be interested to hear that Sascha Silbe (silbe) managed to launch some activities under rainbow inside sugar-jhbuild. You should follow up with him if you'd like to improve the system. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
> The userland application privilege > isolation is hugely important, as we are pushing for making our apps > heavily network oriented, the risks of other network hosts trying to > take advantage of vulnerable apps is huge. A problem with expanding Rainbow to other desktops is that the Rainbow model derives from the Sugar model, which is that only custom-written and therefore "Sugarized" programs run in the Rainbow environment. In other words, Sugar and Rainbow draw a hard line in the sand between "Sugar Activities" and ordinary programs. Rainbow protects Sugar Activities, but doesn't affect ordinary programs. Most other systems don't have that hard line. The shell, the compilers, the clock in the corner of your screen, the browser, are all just programs. They all run with the same privileges and can access the same files and networks. You can just run them anytime, from any shell or script. They don't have to go through a dbus interface, interact with the user, and be passed a file descriptor to read a file; they can and do just call open() or fopen(). This straightforwardness and POSIX compatability doesn't work under Rainbow. This is why so many programs needed to be patched to run under Rainbow -- and why the maintainers of those programs weren't interested in incorporating Rainbow-specific patches. If Rainbow was optional, that would be different. Programs that *want* to run with higher security and less functionality could use it. Most wouldn't even lose any functionality, because Rainbow would only be eliminating options that the programs never use. That was its design goal -- to eliminate capabilities that a program was never designed to use, so the program can't be subverted by an attacker to exploit those capabilities. Its early implementation became more of a straitjacket than a benign helper, with programs failing to run when Rainbow was "turned on" globally. It's a hard job to design and implement a good generic "capabilities" system for a POSIX environment. So far nobody has done it (including Rainbow). The basic ideas of "mark programs with the capabilities they need (or don't need), and have exec() disable the ones the program doesn't need", and "have programs drop excess capabilities after initializing" are good ones. The devil is in the details. The kernel part is relatively simple. It's a harder job to enable capabilities that are far beyond the kernel's ability to police, like "disable this program's ability to listen to a built-in microphone"; that requires security-sensitive changes to a whole variety of libraries, software, and controls. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 18:29, Wade Brainerd wrote: > To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because > it seemed like an interesting challenge. I'm not clear why Sugar needs more > protection from rogue activities than a normal desktop environment has from > rogue applications. > Reinventing the desktop as a constructivist learning environment is a big > enough task for one development team / community to swallow. Reinventing > security is an altogether separate cause. > That said, Rainbow exists, so we don't need to do anything to remove it. So > long as people step up to maintain it and help activity developers fix the > issues they run into. Yeah, that's a very important point. I think we already know the kind of issues we can expect to find and maybe should think twice before throwing out all that knowledge. I don't see Rainbow in Sugar as too controversial, because: - the modifications needed to the Sugar platform are minimal, - most activities don't need to be modified and the ones that do, shouldn't be hard to modify (though there's the issue of unmodified X apps), - we have already agreed that we need a system-wide switch for disabling Rainbow and a way to white list activities that for some reason cannot run yet inside Rainbow. That system-wide switch means that distributors of Sugar will be the ones to decide if they want Rainbow or not. The Sugar community just listens to their deployers and tries to find a way to accommodate that need. No one is forced to use Rainbow, though it's true that activity authors need to take into account a set of limitations if they want their activities to run everywhere. Regards, Tomeu > But Michael, what you seem to be asking for - someone to pick up your solo > project and finish it - almost never happens in software development. Code > is a personal expression of the programmer who wrote it. If it ever does > get finished by someone else, it likely gets rewritten in the process. > Best regards, > Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Tomeu Vizoso wrote: > Michael, > > when several weeks ago you showed me in #sugar your patches to Sugar > and explained the new rainbow concept, I told you that it seemed a > good idea and that the patches looked pretty good. > > As you said Rainbow wasn't ready for 0.84, I told you that we would > talk again when work on 0.86 starts. Which it hasn't yet, afaik. > > So I don't think you should feel sad because of our schedule. All > projects need one and it's good to try stick to it. > > I will repeat that I think Rainbow can be a very important part of > Sugar and that we should see how integration should happen, but I'm > afraid I cannot directly help you with coding, etc because as you know > I'm very tied with 0.84 right now. I think, this describes quite well the current where we stand currently regarding inclusion of Rainbow. I think it is an interesting part to tackle for 0.86. This release cycle was, in terms of changing resources and environment conditions, even worse than the last one. I guess, it can always get worse ;D So there was only so much we could do - and many things that fell of the plate. Anyhow, let's try to look forward - and see what we can do for 0.86. Thanks, Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 12:21 PM, Michael Stone wrote: > For the record, "rainbow" only describes the userland privilege isolation > part. You're right. I conflated the overarching shadow of bitfrost with rainbow. My bad. > I think this would have the effect of making rainbow much less generic than > it currently is. I'm intrigued by your comment. Do you mean "less portable", and in that case what kind of portability are you thinking of? selinux does look more generic than rainbow... And we don't have to go own the selinux path. Is smack simpler, more appropriate to our needs? As you say, selinux, smack and friends have moved forward a lot in the last 2 years. Implementation/documentation/understanding of them has matured enormously. Just having 'permissive' mode is a fantastic thing when developing sw. cheers m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 10:22:07PM +, Gary C Martin wrote: >remind me, Pippy's getting special case hack permission to drive a 8 line >highway through Rainbow security permissions, right? Unfortunately, no. No one has yet completed an implementation of the "gates" needed to guard access to the DS and the "glue" needed to know which DS entries to fork over to which activities. (I got partway through an implementation of the "gates", which are actually fairly simple, but didn't get to the "glue". [8.2.0 intervened.] Later, Scott approached the problem from a completely different angle, i.e. with FUSE filesystems. Hopefully, though, Tomeu's simplified data store will make further work in this area a bit simpler, if any such work occurs.) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 06:05:51PM -0500, Benjamin M. Schwartz wrote: > Sugar/OLPC simply never had SELinux experts I'm pretty sure this is false. For instance, I know that ancient OLPC+RH kernels has SELinux enabled and I know that the SELinux folks at RH have always been excited to help me to understand their work whenever I took the time to ask them questions every few months. >It's hard to write a sandboxer like Rainbow, since it must not only appear >to work, but be verified "secure" to a high degree of confidence. That's >harder still if one is writing in a system in which one is a novice, so >the developers (principally Michael) have instead stuck to technologies >with which they are already expert. This is actually not such a big deal, in my opinion. The killer problem, as I learned from the vserver experience, is that novice activity authors /must/ be able to debug their work in any system which we might hope to ship. I don't think that I have very good ideas on how to make this part workable with technologies that are more complicated or more obscure than Unix DAC. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 11:33:30AM +1300, Martin Langhoff wrote: >You are now talking about the implementation of rainbow that provides >userland privilege isolation. For the record, "rainbow" only describes the userland privilege isolation part. The rest is just "OFW, olpcrd, olpc-update, OATS...". (If somebody knows a better way to explain this stuff, speak up!) > One thing that I wonder is whether in the push to make our OS more generic it > would make sense to push rainbow in the direction of things like smack or > selinux. I think this would have the effect of making rainbow much less generic than it currently is. On the other hand, it might still be worth doing if it made it much easier to implement important features. > Maybe rainbow could insta-isolate creating selinux profiles for activities? I've been wondering about this for some time. Basically, while my reaction when it was initially proposed it was lukewarm, for all the usual reasons [1]. Since then, I've been very gradually warming to the idea, in part as SELinux matures, in part as I get to know the technology and people [2] better, and in part as I run up against limitations of the simple Unix approach that I've taken for the last year. Therefore, while it's not how /I/ intend to proceed in the near future, I'm happy to try to work with people who feel differently. I definitely have some ideas on the subject. Michael [1]: http://lists.laptop.org/pipermail/security/2008-January/000370.html [2]: http://danwalsh.livejournal.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, 24 Feb 2009, Benjamin M. Schwartz wrote: > Martin Langhoff wrote: >> Maybe my ignorance on matters selinux is showing? ;-) > > You are not alone. Sugar/OLPC simply never had SELinux experts who > volunteered to work on Rainbow. We still don't (raise your hand if you > consider yourself proficient at writing SELinux policy!). So does anyone want to become expert at writing SELinux policy? Someone who might benefit from a Red Hat internship in Westford at the feet of the master of SELinux, Dan Walsh? http://danwalsh.livejournal.com/26904.html --g -- Got an XO that you're not using? Loan it to a needy developer! [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Martin Langhoff wrote: > Maybe my ignorance on matters selinux is showing? ;-) You are not alone. Sugar/OLPC simply never had SELinux experts who volunteered to work on Rainbow. We still don't (raise your hand if you consider yourself proficient at writing SELinux policy!). It's hard to write a sandboxer like Rainbow, since it must not only appear to work, but be verified "secure" to a high degree of confidence. That's harder still if one is writing in a system in which one is a novice, so the developers (principally Michael) have instead stuck to technologies with which they are already expert. --Ben P.S. The SELinux entry on Wikipedia contains the following gem: "Isolation of processes can also be accomplished by mechanisms like virtualization; the OLPC project, for example, sandboxes individual applications in lightweight Vservers." signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 5:24 AM, Michael Stone wrote: > In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I > have > tried to clear the way for them to use it on all the platforms they care about > by simplifying it, by making it more generically useful, by writing some basic > .deb and .rpm packaging in order to ease testing, Hi Michael, what rainbow provides is very important. The trusted-OS checks from the firmware up are important. The userland application privilege isolation is hugely important, as we are pushing for making our apps heavily network oriented, the risks of other network hosts trying to take advantage of vulnerable apps is huge. You are now talking about the implementation of rainbow that provides userland privilege isolation. One thing that I wonder is whether in the push to make our OS more generic it would make sense to push rainbow in the direction of things like smack or selinux. Maybe rainbow could insta-isolate creating selinux profiles for activities? Maybe my ignorance on matters selinux is showing? ;-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote: I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. It's not that Sugar needs more protection than currently existing desktop environments, but rather that _all_ desktop environments need it (but currently lack it). In fact, I hope that other DEs will start using Rainbow as well, even if just optionally. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html Thanks for your work! I sure hope it'll get used instead of dropped, it's the #1 reason I looked into Sugar in the first place and the one thing I miss most on regular "desktops" (I'm sometimes using vnc running under different UIDs for the same purpose). What exactly do I need to do to try it out within sugar-jhbuild on Ubuntu intrepid (amd64)? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On 24 Feb 2009, at 17:52, Wade Brainerd wrote: > On Tue, Feb 24, 2009 at 12:41 PM, Benjamin M. Schwartz > > wrote: > They are a single, indivisible cause, and also the entire reason for > the > existence of Sugar. > > Many operating systems provide users with a set of powerful tools for > manipulating ideas and data. Sugar's purpose is to add another > dimension: > to encourage users to modify and share the tools themselves. To > that end, > if my friend sends me a modified copy of an activity, I must be able > to > run it without fear of wrecking my system. > > On the contrary, learning to develop software is almost impossible > without wrecking your system once or twice. > > Backups are the correct solution to this problem, not some crazy > security system. When all you have is a hammer, everything looks > like a nail. I do very much agree about back-ups (Martin's and others school-server back-up work is in invaluable here), but the promise of Rainbow is not just about limiting the possibilities for how a system could get accidently/maliciously wrecked. For instance, how do you like the idea of 'a friend' silently harvesting all the Journal photos your kid has taken via a compromised/modified activity**? **actually Pippy and the slideshow example really creeps me out for just that reason – remind me, Pippy's getting special case hack permission to drive a 8 line highway through Rainbow security permissions, right? I know Rainbow, as currently implemented, is lacking in certain areas – but Rainbow is providing something I think is valuable, that's not available elsewhere, and in a manor appropriate for the non-specialist target audience. --Gary P.S. Maybe I'm just paranoid; v.happy to be corrected. > -Wade > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Hi, On Dienstag, 24. Februar 2009, Wade Brainerd wrote: > > Many operating systems provide users with a set of powerful tools for > > manipulating ideas and data. Sugar's purpose is to add another > > dimension: to encourage users to modify and share the tools themselves. > > To that end, if my friend sends me a modified copy of an activity, I must > > be able to run it without fear of wrecking my system. > On the contrary, learning to develop software is almost impossible without > wrecking your system once or twice. Ahem, sugar is aimed at kids, not at people developing software or learning how to do system administration. > Backups are the correct solution to this problem, not some crazy security > system. When all you have is a hammer, everything looks like a nail. It seems to me your hammer is called "backup". ;-) regards, Holger, who thinks that rainbow is extremly needed signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On 24.02.2009, at 20:43, Sascha Silbe wrote: > On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote: > >> I'm not clear why Sugar needs more protection from rogue activities >> than a normal desktop environment has from rogue applications. > It's not that Sugar needs more protection than currently existing > desktop environments, but rather that _all_ desktop environments > need it (but currently lack it). In fact, I hope that other DEs will > start using Rainbow as well, even if just optionally. +1 Besides, if we didn't feel that children deserved better than the currently popular systems we would not have started Sugar development in the first place. Security is one aspect of this. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 03:45:33PM -0300, Daniel Drake wrote: >Hi Michael, > >2009/2/24 Michael Stone : >> In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. > >How realistic is it to make rainbow something generic that all environments >and applications could use? I consider it a realistic goal, with a few caveats. The rainbow-0.8.* redesign takes a big step in this direction by introducing an exec-wrapper interface which can be embedded in fd.o .desktop launchers, used from the CLI, and used by custom launchers like Sugar with equal ease. Privilege is acquired from a setuid helper; e.g. sudo. The design and automated tests now support limited concurrent multi-user operation, though the implementation needs a bit more work in order to operate securely in a multi-user environment. The only notable dependencies so far are on python and glibc. The caveats are: a) Usability sucks at the moment. For example, I need to implement some sort of garbage collection and some kind of "user-facing" UI, which might just be a simpler CLI wrapper. I probably also need to write a man page and to introduce more diverse error codes. b) We're going to need recent kernels for the fancier containerization stuff that I'd like to work on in the future. (Fortunately, upstream seems to be making good progress on the features I want :) c) I don't have any good idea how well or poorly the current design scales. (I think it will work fine for desktop use. I'm just not sure how far beyond that it will stretch.) More questions? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, 24 Feb 2009, Carol Farlow Lerche wrote: > . the purpose (not in security speak but in terms of the benefits it brings > to end users), also why should rainbow be used instead of one of the many other sets of tools available to distros for locking down a desktop (SELinux, or other LSMs)? can/should rainbow be modified to use the LSM hooks so that it can be used with standard systems? or is it really doing something that is Sugar specific? how should/could rainbow work with non-sugar apps? (normal X learning apps running on an XO to use an example raised in another post in this thread) how should/could apps work around what seems like a rainbow limitation to let one binary be used for multiple 'apps' (for example gmail + browse or the X desktop wrapper) I apologize if you already answered this in your documentation, but these sorts of concepts were not even being discussed a year or so ago, and the answers are not generally known. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Michael, I'm happy to continue this discussion off-list if you or others feel it is inappropriate to carry it on here. However, to respond to your mail: > Thanks you for this detailed critique of my documentation efforts to date. > One > thing that I've (obviously) struggled with is understanding which audiences > require which sorts of documentation. Your continued assistance untangling > this > mess is most appreciated. > I would be happy to supply detailed editorial comments to any effort you make to provide a unified Rainbow document. ... write > a tutorial about it that would make it more apparent how much is actually > implemented and what an activity can do with it. > I'll see what I can cook up. You might consider: Specifically list aspects of program operation that are forbidden or limited in the application, by default, under the current implementation. Tell why the restriction is there, from a user-benefit perspective. If these restrictions can be overcome by configuration files or programmatic calls, list these under the restriction description. Point out explicitly where a developer would see evidence of the restriction being called into play (which log, e.g., and where is it? Do you need to turn on logging in some way to see the messages?) You might want to create a separate tutorial from the standpoint of other desktop environment developers, along the lines of "what to do to implement Rainbow in your environment." I already here voices chiming in that all anyone needs is to read the code. But could those chiming voices please recognize that there is a difference between the effort people will go to in conforming to or using a feature that they don't entirely belive in, (rather than just turning it off) compared to being provided easy access and understanding. > Do you have an example of documentation which you think really nailed the > divide between "what is needed", "what exists", "how good is it?", and "how > do > I use it?" > It is uncommon to document future features unless they are realistically expected to be implemented soon, except perhaps as an appendix of unresolved issues, or "bugs" sections as in man pages. But frequently documentation addresses features that are only present in later versions. Often this is set off by color, inline images of some kind or similar visual cues. > > As it happens, the main feature which exists is primitive filesystem > isolation. > Well, I'd stick to documenting that, and save the blue sky for an appendix. For me, these questions are largely answered by the statements, scattered > throughout the system, that rainbow operates by inventing new uids for > programs > which it is asked to isolate. However, I can certainly lay things out more > explicitly. Thank you for the reminder about active vs. passive voice. > Persons with a deep or even a moderate interest in security would understand that that was the case, but we're talking about a hoped-for community of activity developers including educators and learners that have so far proved unable to cross a rather high barrier of entry. What are the concerns of activity developers? > > To date, the only one which I have heard clearly articulated is: > > "How do I turn rainbow off for testing?" > which, in fact, is answered in the "For Activity Developers" section > In this case, perhaps we should contemplate why someone would want to turn off rainbow, rather than using information that tells them what Rainbow is preventing. Can I offer the analogy of the dreaded Windows security problems in which applications written for early versions of Windows silently broke when MS introduced new access violation error returns that the programs were unaware of? These errors could often be eliminated by end users through granting constrained privileges to various Windows resources, but instead most people just did the simple thing. They ran the application as administrator (analogous to turning Rainbow off). All the bad consequences followed. Btw I don't think it was just that developers turned off Rainbow. Users did too, because activities had been written outside the context of Rainbow, then it was turned on. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Future of Rainbow + Sugar?
Hi Michael, 2009/2/24 Michael Stone : > In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. How realistic is it to make rainbow something generic that all environments and applications could use? In an ideal world, such a security system should be available to everyone, not just sugar users -- but I'm not sure which technical challenges are entailed. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
--- Wade Brainerd wrote:
> Backup, a far more useful and achievable
> solution to this problem.
I don't see how Rainbow, something _working_ and pretty usable on my XO right
now, is usefully compared to "backup", a solution similar in specificity to the
aphorism "be careful" and one that doesn't resemble anything working on my XO
right now. I think there are about a ton of threads about how backup might be
implemented on {,xs-}de...@l.o.
> Regards,
> -Wade
Martin
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 1:30 PM, wrote: > bert wrote: > > On 24.02.2009, at 19:09, Carol Farlow Lerche wrote: > ... > > > Asking for better documentation doesn't imply that the facility is > > > new. It recognizes that development has reached a local minimum in > > > an important component that is not well understood by many. My post > > > was a request to the most knowledgeable person, Michael to do the > > > service of taking the time to write a document that clearly lays out > > > > > > . the purpose (not in security speak but in terms of the benefits > > > it brings to end users), > > for my part, i've always felt that it's this first point of > carol's that's been missing from the docs. the functional > overview is very important: as a developer, you're asking me to > implement a bunch of new API functionality simply to make a > simple program (which may already be working well in most other unix > environments) functional. i'd like to be sold on the concept > first, before having to do a bunch of work for no (apparent) benefit > to me or my program. I'm going to bow out of this thread (back to work!) but I wanted to bring up one last point regarding Rainbow's cost to Sugar. It is my sincere hope that sometime in the future Sugar will gain the ability to seamlessly launch normal X applications alongside activities. There are a great many educational Linux applications out there that would fill in gaps in our activity lineup. I fear that Rainbow will be an obstacle to achieving this goal, as we don't have the ability to fix every application in existence to conform to our non-standard security model, and emulation hacks will never just work. Best, Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
bert wrote: > On 24.02.2009, at 19:09, Carol Farlow Lerche wrote: ... > > Asking for better documentation doesn't imply that the facility is > > new. It recognizes that development has reached a local minimum in > > an important component that is not well understood by many. My post > > was a request to the most knowledgeable person, Michael to do the > > service of taking the time to write a document that clearly lays out > > > > . the purpose (not in security speak but in terms of the benefits > > it brings to end users), for my part, i've always felt that it's this first point of carol's that's been missing from the docs. the functional overview is very important: as a developer, you're asking me to implement a bunch of new API functionality simply to make a simple program (which may already be working well in most other unix environments) functional. i'd like to be sold on the concept first, before having to do a bunch of work for no (apparent) benefit to me or my program. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
--- Carol Farlow Lerche wrote: > things that the activity developers can and can't do As an aside, I yesterday uploaded a simple activity to addons.sugarlabs.org. This activity runs on os767 and soas (afaik). Your post and this discussion made me realize that I hadn't had to think about Rainbow *at all* and things Just Worked. For simple activities and/or barrier-to-entry discussions, that observation seems germane. Martin ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 08:56:06AM -0800, Carol Farlow Lerche wrote: >Michael, I think your work on Rainbow is very important, but I think it is a >bit opaque. Carol, Thanks you for this detailed critique of my documentation efforts to date. One thing that I've (obviously) struggled with is understanding which audiences require which sorts of documentation. Your continued assistance untangling this mess is most appreciated. >Perhaps you could improve your documentation and as well write >a tutorial about it that would make it more apparent how much is actually >implemented and what an activity can do with it. I'll see what I can cook up. >So here's an example. In the Rainbow page on w.l.o you refer to >http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD for more >information. Yet this file has several locutions of the form "This can be >implemented" and "I believe but have not confirmed" which leave the reader >unclear as to which services have actually been implemented. Do you have an example of documentation which you think really nailed the divide between "what is needed", "what exists", "how good is it?", and "how do I use it?" >Hopping over to Low-Level Activity API the information about security doesn't >correlate with the permissions referred to in the txt file. The purpose of the rainbow.txt document was to argue that a design /existed/ which would satisfy enough of the overall goals to be worth pursuing. The purpose of the Low-Level Activity API documentation is to explain what features of rainbow exist and can be twiddled by activities. As it happens, the main feature which exists is primitive filesystem isolation. >Also you leave ambiguities for the reader by using the passive voice >throughout these articles. Changing from passive to active voice answers >many questions for the reader. Here is an example: > >"All writing to the file system is restricted to subdirectories of the path >given in the SUGAR_ACTIVITY_ROOT environment variable." > >Well, we know that isn't true in all cases, because activities get installed >by Sugar outside that subtree. So possibly you mean "Rainbow prevents any >activity launched by the Sugar shell from writing to any directories except >those under SUGAR_ACTIVITY_ROOT". Or do you? Any exceptions? What about >reading files elsewhere in the file system? For me, these questions are largely answered by the statements, scattered throughout the system, that rainbow operates by inventing new uids for programs which it is asked to isolate. However, I can certainly lay things out more explicitly. Thank you for the reminder about active vs. passive voice. >I think demystifying Rainbow within a comprehensive document containing a >section specifically aimed at the concerns of activity developers would go a >long way toward expanding its use. What are the concerns of activity developers? To date, the only one which I have heard clearly articulated is: "How do I turn rainbow off for testing?" which, in fact, is answered in the "For Activity Developers" section. http://wiki.laptop.org/go/Rainbow#For_Activity_Developers Obviously, a couple of people also found it helpful to tweak the isolation options in detailed ways as discussed in the API docs you cited earlier. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On 24.02.2009, at 19:09, Carol Farlow Lerche wrote: > Bert, Are you satisfied with the number of activity developers? > Are you satisfied with the number of developers within the > deployments? Have you noticed the periodic questions on the > developer-oriented lists about Rainbow security and whether it is > causing mysterious symptoms? I'm not, and I have. I am virtually certain that Rainbow is not the major obstacle to getting more activity developers. > Asking for better documentation doesn't imply that the facility is > new. It recognizes that development has reached a local minimum in > an important component that is not well understood by many. My post > was a request to the most knowledgeable person, Michael to do the > service of taking the time to write a document that clearly lays out > > . the purpose (not in security speak but in terms of the benefits > it brings to end users), > > . the relevance of APIs versus packaging elements versus choices by > the sugar shell/infrastructure developers, > > . things that the activity developers can and can't do (given that > I, at least, hope that new developers will participate, who have > preconceptions from other environments), > > Things that are hoped for in future development (well delimited from > things that are there now.) > > Good documentation is hard, and wiki pages are only good > documentation if the wiki is maintained with great discipline (which > I fear is not the case at w.l.o). But for a subtle and complex > feature such as Rainbow, good documentation would be a motivator for > use both within and outside the sugar community. Agreed. However, what activity authors need to know about rainbow is documented, and it really is not much. For example, here http://wiki.laptop.org/go/Low-level_Activity_API#Security This is not even a full page, and if activity authors use the Python Sugar toolkit they can worry even less about this. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Bert, Are you satisfied with the number of activity developers? Are you satisfied with the number of developers within the deployments? Have you noticed the periodic questions on the developer-oriented lists about Rainbow security and whether it is causing mysterious symptoms? I'm not, and I have. Asking for better documentation doesn't imply that the facility is new. It recognizes that development has reached a local minimum in an important component that is not well understood by many. My post was a request to the most knowledgeable person, Michael to do the service of taking the time to write a document that clearly lays out . the purpose (not in security speak but in terms of the benefits it brings to end users), . the relevance of APIs versus packaging elements versus choices by the sugar shell/infrastructure developers, . things that the activity developers can and can't do (given that I, at least, hope that new developers will participate, who have preconceptions from other environments), Things that are hoped for in future development (well delimited from things that are there now.) Good documentation is hard, and wiki pages are only good documentation if the wiki is maintained with great discipline (which I fear is not the case at w.l.o). But for a subtle and complex feature such as Rainbow, good documentation would be a motivator for use both within and outside the sugar community. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:57 PM, Michael Stone wrote: > I'm not clear why Sugar needs more protection from rogue activities than a >> normal desktop environment has from rogue applications. >> > > The justification which interests me the most goes something like: "strong > protections mean that there is less risk that kids and teachers will break > things by installing software on their machines; therefore, educational > innovations will spread faster." See my comment regarding Backup, a far more useful and achievable solution to this problem. > Reinventing the desktop as a constructivist learning environment is a big >> enough task for one development team / community to swallow. Reinventing >> security is an altogether separate cause. >> > > There is no reinvention taking place here; instead, we are using both > long-standing OS features (discretionary access control; memory isolation) > and > novel OS features (network containerization, cgroup-based memory resource > limits) in new combinations as they become available. What has changed is > that > the Sugar UI and user expectations permit concentrated use of these > features. In a nutshell, all this refers to Sandboxing, which seems to be the "new hotness" in software security these days. I type this email in Google Chrome, which is a good example of that. There's nothing wrong with sandboxing or other new security techniques, I just argue that their purpose is *orthogonal* to the goals of Sugar. Apologies for incorrectly assuming that you wanted someone to finish Rainbow. As far as I know the current implementation is without major issues, if some of the more advanced features of Bitfrost are not yet implemented. Regards, -Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote: >To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because >it seemed like an interesting challenge. So you've said in the past. What of it? >I'm not clear why Sugar needs more protection from rogue activities than a >normal desktop environment has from rogue applications. The justification which interests me the most goes something like: "strong protections mean that there is less risk that kids and teachers will break things by installing software on their machines; therefore, educational innovations will spread faster." >Reinventing the desktop as a constructivist learning environment is a big >enough task for one development team / community to swallow. Reinventing >security is an altogether separate cause. There is no reinvention taking place here; instead, we are using both long-standing OS features (discretionary access control; memory isolation) and novel OS features (network containerization, cgroup-based memory resource limits) in new combinations as they become available. What has changed is that the Sugar UI and user expectations permit concentrated use of these features. >That said, Rainbow exists, so we don't need to do anything to remove it. So >long as people step up to maintain it and help activity developers fix the >issues they run into. The issue is that rainbow "has been maintained" and its downstream users (e.g. Sugar) need to give some feedback on the intermediate results so that there will be time for its upstream author to respond to that feedback. >But Michael, what you seem to be asking for - someone to pick up your solo >project and finish it Thank you, no. I apologize if my writing contributed to this gross misunderstanding of my purpose. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:41 PM, Benjamin M. Schwartz < bmsch...@fas.harvard.edu> wrote: > They are a single, indivisible cause, and also the entire reason for the > existence of Sugar. > > Many operating systems provide users with a set of powerful tools for > manipulating ideas and data. Sugar's purpose is to add another dimension: > to encourage users to modify and share the tools themselves. To that end, > if my friend sends me a modified copy of an activity, I must be able to > run it without fear of wrecking my system. On the contrary, learning to develop software is almost impossible without wrecking your system once or twice. Backups are the correct solution to this problem, not some crazy security system. When all you have is a hammer, everything looks like a nail. -Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Hi Carol, you make it sound as if Rainbow was new and unknown and Michael was pushing it. That's a bit unfair. Rainbow has been shipping in the OLPC releases for quite a while, and activity authors in general do know that they simply have to respect the designated directories for saving files. For example, they do know that SUGAR_ACTIVITY_ROOT (provided by Rainbow for runtime use) is something else altogether than SUGAR_BUNDLE_PATH (set by Sugar to the installation directory). Rainbow is one of the most generally useful things brought into being by OLPC. Since Sugar activities were specifically designed to work with it, it would be a shame to not use this enhanced security framework. In particular since Sugar aims at users who need all the protection they can get. Integration with jhbuild has been problematic since the rainbow demon needs to run with super user privileges, and it would need to mess with the user management of the host machine. But it should work very well in SoaS and I for one would appreciate if it was integrated and enabled there. - Bert - On 24.02.2009, at 17:56, Carol Farlow Lerche wrote: > Michael, I think your work on Rainbow is very important, but I think > it is a bit opaque. Perhaps you could improve your documentation > and as well write a tutorial about it that would make it more > apparent how much is actually implemented and what an activity can > do with it. > > So here's an example. In the Rainbow page on w.l.o you refer to > http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD > for more information. Yet this file has several locutions of the > form "This can be implemented" and "I believe but have not > confirmed" which leave the reader unclear as to which services have > actually been implemented. Hopping over to Low-Level Activity API > the information about security doesn't correlate with the > permissions referred to in the txt file. > > Also you leave ambiguities for the reader by using the passive voice > throughout these articles. Changing from passive to active voice > answers many questions for the reader. Here is an example: > > "All writing to the file system is restricted to subdirectories of > the path given in the SUGAR_ACTIVITY_ROOT environment variable." > > Well, we know that isn't true in all cases, because activities get > installed by Sugar outside that subtree. So possibly you mean > "Rainbow prevents any activity launched by the Sugar shell from > writing to any directories except those under > SUGAR_ACTIVITY_ROOT". Or do you? Any exceptions? What about > reading files elsewhere in the file system? > > The scattershot documentation within several wiki pages and text > files of unknown currency is also a problem. How about a unified > document befitting such an important aspect of the Sugar architecture. > > I think demystifying Rainbow within a comprehensive document > containing a section specifically aimed at the concerns of activity > developers would go a long way toward expanding its use. > > > Carol Lerche > > > On Tue, Feb 24, 2009 at 8:24 AM, Michael Stone > wrote: > On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: > >[Also, I'm hearing whispers of 'no Rainbow' after Joyride.] > > Mikus, > > In my view, it's up to the SugarLabs folks to use Rainbow or to drop > it. I have > tried to clear the way for them to use it on all the platforms they > care about > by simplifying it, by making it more generically useful, by writing > some basic > .deb and .rpm packaging in order to ease testing, and by writing > Sugar patches > which cause Sugar to use it. Unfortunately, in the two months since I > announced this work: > >http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html > > and since I spoke about it at Fudcon Boston in January, I have > received no > feedback more serious than a (kind) thank-you note from Walter, let > alone > testing, bug reports, or patches. As you might imagine, this > overwhelming > response leaves me more than a little bit discouraged. > > Now, it could certainly be the case that there's more work that I > need to do in > the form of documenting, testing, or pushing my recent rainbows > before people > will be excited about trying them out and, if that's the case, > someone should > tell me. Since no one has done so to date, despite repeated > overtures, I've > mostly come to believe that no one cares. > > Do you know differently? > > Michael > > P.S. - I find this state of affairs particularly sad, since I thi
Re: [Sugar-devel] Future of Rainbow + Sugar?
Wade Brainerd wrote: > To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because > it seemed like an interesting challenge. I'm not clear why Sugar needs more > protection from rogue activities than a normal desktop environment has from > rogue applications. > > Reinventing the desktop as a constructivist learning environment is a big > enough task for one development team / community to swallow. Reinventing > security is an altogether separate cause. They are a single, indivisible cause, and also the entire reason for the existence of Sugar. Many operating systems provide users with a set of powerful tools for manipulating ideas and data. Sugar's purpose is to add another dimension: to encourage users to modify and share the tools themselves. To that end, if my friend sends me a modified copy of an activity, I must be able to run it without fear of wrecking my system. Users naturally want to do this. To see what happens when the operating system doesn't support it, just look at the wave upon wave of e-mail viruses that plagued Windows for so many years. Without support for safe collaborative development of this sort, Sugar has little to recommend it over XFCE and similar gtk-based iconic user interfaces. We are getting there, and with the latest improvements to view-source and Rainbow, we are beginning to have the basics in place. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because it seemed like an interesting challenge. I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. That said, Rainbow exists, so we don't need to do anything to remove it. So long as people step up to maintain it and help activity developers fix the issues they run into. But Michael, what you seem to be asking for - someone to pick up your solo project and finish it - almost never happens in software development. Code is a personal expression of the programmer who wrote it. If it ever does get finished by someone else, it likely gets rewritten in the process. Best regards, Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Rainbow in jhbuild would help debugging. I don't think I am along=e in using it as a development environment. -walter On Tue, Feb 24, 2009 at 12:09 PM, Michael Stone wrote: > On Tue, Feb 24, 2009 at 05:41:09PM +0100, Sascha Silbe wrote: >> On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: >> >>> >>> http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html >> Thanks for your work! I sure hope it'll get used instead of dropped, >> it's the #1 reason I looked into Sugar in the first place and the one >> thing I miss most on regular "desktops" (I'm sometimes using vnc running >> under different UIDs for the same purpose). > > Sascha, > > Thanks very much for the kind reply; it's really helpful to hear that someone > thinks this work is worth pursuing. > >> What exactly do I need to do to try it out within sugar-jhbuild on >> Ubuntu intrepid (amd64)? > > Never having used sugar-jhbuild, it's hard for me to say precisely. My guess > is > that you should teach jhbuild to compile and install rainbow, then apply my > patches to sugar (rebasing if needed, since they're now two months stale): > > http://dev.laptop.org/git/users/mstone/sugar-toolkit > http://dev.laptop.org/git/users/mstone/sugar > > then see what breaks. (Which might be everything, since, as I said, rainbow > has > never been tested w/ jhbuild.) > > In the mean-time, let's start updating http://wiki.laptop.org/go/Rainbow with > what you learn so that it becomes easier for others to assist. > > Michael > > P.S. - Let me know where more help is needed and I'll be happy to try to get > you unstuck. > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 05:41:09PM +0100, Sascha Silbe wrote: > On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: > >> >> http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html > Thanks for your work! I sure hope it'll get used instead of dropped, > it's the #1 reason I looked into Sugar in the first place and the one > thing I miss most on regular "desktops" (I'm sometimes using vnc running > under different UIDs for the same purpose). Sascha, Thanks very much for the kind reply; it's really helpful to hear that someone thinks this work is worth pursuing. > What exactly do I need to do to try it out within sugar-jhbuild on > Ubuntu intrepid (amd64)? Never having used sugar-jhbuild, it's hard for me to say precisely. My guess is that you should teach jhbuild to compile and install rainbow, then apply my patches to sugar (rebasing if needed, since they're now two months stale): http://dev.laptop.org/git/users/mstone/sugar-toolkit http://dev.laptop.org/git/users/mstone/sugar then see what breaks. (Which might be everything, since, as I said, rainbow has never been tested w/ jhbuild.) In the mean-time, let's start updating http://wiki.laptop.org/go/Rainbow with what you learn so that it becomes easier for others to assist. Michael P.S. - Let me know where more help is needed and I'll be happy to try to get you unstuck. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Future of Rainbow + Sugar?
Michael, when several weeks ago you showed me in #sugar your patches to Sugar and explained the new rainbow concept, I told you that it seemed a good idea and that the patches looked pretty good. As you said Rainbow wasn't ready for 0.84, I told you that we would talk again when work on 0.86 starts. Which it hasn't yet, afaik. So I don't think you should feel sad because of our schedule. All projects need one and it's good to try stick to it. I will repeat that I think Rainbow can be a very important part of Sugar and that we should see how integration should happen, but I'm afraid I cannot directly help you with coding, etc because as you know I'm very tied with 0.84 right now. Hope it clarifies, Tomeu On Tue, Feb 24, 2009 at 17:24, Michael Stone wrote: > On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: >>[Also, I'm hearing whispers of 'no Rainbow' after Joyride.] > > Mikus, > > In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I > have > tried to clear the way for them to use it on all the platforms they care about > by simplifying it, by making it more generically useful, by writing some basic > .deb and .rpm packaging in order to ease testing, and by writing Sugar patches > which cause Sugar to use it. Unfortunately, in the two months since I > announced this work: > > http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html > > and since I spoke about it at Fudcon Boston in January, I have received no > feedback more serious than a (kind) thank-you note from Walter, let alone > testing, bug reports, or patches. As you might imagine, this overwhelming > response leaves me more than a little bit discouraged. > > Now, it could certainly be the case that there's more work that I need to do > in > the form of documenting, testing, or pushing my recent rainbows before people > will be excited about trying them out and, if that's the case, someone should > tell me. Since no one has done so to date, despite repeated overtures, I've > mostly come to believe that no one cares. > > Do you know differently? > > Michael > > P.S. - I find this state of affairs particularly sad, since I think there's an > /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing > all > the recent hard work the kernel folks have been putting in on network > containerization and memory-resource cgroups "to the masses". > ___ > 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
Re: [Sugar-devel] Future of Rainbow + Sugar?
Michael, I think your work on Rainbow is very important, but I think it is a bit opaque. Perhaps you could improve your documentation and as well write a tutorial about it that would make it more apparent how much is actually implemented and what an activity can do with it. So here's an example. In the Rainbow page on w.l.o you refer to http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD for more information. Yet this file has several locutions of the form "This can be implemented" and "I believe but have not confirmed" which leave the reader unclear as to which services have actually been implemented. Hopping over to Low-Level Activity API the information about security doesn't correlate with the permissions referred to in the txt file. Also you leave ambiguities for the reader by using the passive voice throughout these articles. Changing from passive to active voice answers many questions for the reader. Here is an example: "All writing to the file system is restricted to subdirectories of the path given in the SUGAR_ACTIVITY_ROOT environment variable." Well, we know that isn't true in all cases, because activities get installed by Sugar outside that subtree. So possibly you mean "Rainbow prevents any activity launched by the Sugar shell from writing to any directories except those under SUGAR_ACTIVITY_ROOT". Or do you? Any exceptions? What about reading files elsewhere in the file system? The scattershot documentation within several wiki pages and text files of unknown currency is also a problem. How about a unified document befitting such an important aspect of the Sugar architecture. I think demystifying Rainbow within a comprehensive document containing a section specifically aimed at the concerns of activity developers would go a long way toward expanding its use. Carol Lerche On Tue, Feb 24, 2009 at 8:24 AM, Michael Stone wrote: > On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: > >[Also, I'm hearing whispers of 'no Rainbow' after Joyride.] > > Mikus, > > In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I > have > tried to clear the way for them to use it on all the platforms they care > about > by simplifying it, by making it more generically useful, by writing some > basic > .deb and .rpm packaging in order to ease testing, and by writing Sugar > patches > which cause Sugar to use it. Unfortunately, in the two months since I > announced this work: > > > http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html > > and since I spoke about it at Fudcon Boston in January, I have received no > feedback more serious than a (kind) thank-you note from Walter, let alone > testing, bug reports, or patches. As you might imagine, this overwhelming > response leaves me more than a little bit discouraged. > > Now, it could certainly be the case that there's more work that I need to > do in > the form of documenting, testing, or pushing my recent rainbows before > people > will be excited about trying them out and, if that's the case, someone > should > tell me. Since no one has done so to date, despite repeated overtures, I've > mostly come to believe that no one cares. > > Do you know differently? > > Michael > > P.S. - I find this state of affairs particularly sad, since I think there's > an > /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing > all > the recent hard work the kernel folks have been putting in on network > containerization and memory-resource cgroups "to the masses". > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." -- Upton Sinclair ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Future of Rainbow + Sugar?
Michael Stone wrote: > In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. Now that Sugar was made more modular, I think it's up to the individual distributors to make a choice. It might be enabled by default on XOOS, disabled by default on F11, and so on. > Now, it could certainly be the case that there's more work that I need to do > in > the form of documenting, testing, or pushing my recent rainbows before people > will be excited about trying them out and, if that's the case, someone should > tell me. Since no one has done so to date, despite repeated overtures, I've > mostly come to believe that no one cares. Is there any work that needs to be done Sugar side in order to adapt it to your refactored version of Rainbow? If so, I'm afraid that: 1) nobody but you understands Rainbow well enough to come up with a proper patch 2) it might be too late for the 0.84 release cycle at this point. > P.S. - I find this state of affairs particularly sad, since I think there's an > /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing > all > the recent hard work the kernel folks have been putting in on network > containerization and memory-resource cgroups "to the masses". I'm with you on this. Actually, Rainbow is the only part of OLPC's security I find actually beneficial for the user. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: >[Also, I'm hearing whispers of 'no Rainbow' after Joyride.] Mikus, In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I have tried to clear the way for them to use it on all the platforms they care about by simplifying it, by making it more generically useful, by writing some basic .deb and .rpm packaging in order to ease testing, and by writing Sugar patches which cause Sugar to use it. Unfortunately, in the two months since I announced this work: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html and since I spoke about it at Fudcon Boston in January, I have received no feedback more serious than a (kind) thank-you note from Walter, let alone testing, bug reports, or patches. As you might imagine, this overwhelming response leaves me more than a little bit discouraged. Now, it could certainly be the case that there's more work that I need to do in the form of documenting, testing, or pushing my recent rainbows before people will be excited about trying them out and, if that's the case, someone should tell me. Since no one has done so to date, despite repeated overtures, I've mostly come to believe that no one cares. Do you know differently? Michael P.S. - I find this state of affairs particularly sad, since I think there's an /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing all the recent hard work the kernel folks have been putting in on network containerization and memory-resource cgroups "to the masses". ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Rainbow and P_NETWORK heads-up.
Folks, Bernie has been gently pushing me to revive some of my older security work. To that end, we've pushed the first versions of rainbow-0.8.x into Ubuntu [1] and Fedora [2], rebased the necessary sugar patches [3], and rewritten my sys_disablenetwork() attempt into cool new RLIMIT_NETWORK code [4]. Be warned -- this code is really, really raw, full of bugs, may eat babies, etc. It's almost certainly going to change around a bit in the foreseeable future. However, it's definitely worth glancing at, both for review purposes, to help round off rough edges, and to get it closer to shippability in all your favorite distros. Thanks in advance for your interest, support, and assistance in making this real. :) Regards, Michael [1]: https://launchpad.net/~codewiz/+archive [2]: rainbow-0.8.x pushed into rawhide a few days ago [3]: http://dev.laptop.org/git/users/mstone/sugar + http://dev.laptop.org/git/users/mstone/sugar-toolkit [4]: http://dev.laptop.org/git/users/mstone/olpc-2.6 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
rainbow preloading disabled in joyride (temporarily?)
Hi, rainbow's python module preloading causes a lot of activity breakage in joyride (any activity based on gstreamer such as Record, Chat, etc). Some reasons are detailed here: http://dev.laptop.org/ticket/9035 I just released rainbow-0.7.27 which turns off preloading. It will be in the next joyride. Having activities that start a bit slower than usual is better than having activities that do not start at all. This doesn't mean that preloading is turned off forever (although some of us would like that), but it is certainly disabled until someone comes up with a solution for the above bug at the very least. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: InputMethod doesn't work with Rainbow activity isolation
On Thu, Nov 6, 2008 at 7:31 AM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote: > On Sat, Nov 1, 2008 at 9:08 AM, Korakurider <[EMAIL PROTECTED]> wrote: >> Hi. >> >> I have difficulty to make Japanese input method (SCIM-anthy) work on 8.2-767. >> Input method can't be activated on activity window even if hit >> Ctrl-Space (IME on/off switch). >> After some experiment I found that IME can be activated if activity >> isolation is disabled. >> If isolation is enabled, I can activate IME only in terminal activity. >> Any clue to make it work even with isolation? >> >> Sayamindu, >> Just a quick report though ... >> I also tested ibus-anthy. >> Now installation is straightforward with yum. >> While it is also affected by isolation, I can activate it and input >> Japanese string >> into activity window. >> > > > Could you replace the attached files in your XO (/usr/bin/olpc-session > and /usr/lib/python2.5/site-packages/rainbow/service.py) and test ? > (ideally rainbow should be enabled) > > I tested with scim-anthy, and it works for me (to be on the safe side, > edit ~/.i18n and set it to en_US.UTF-8) > > All activities seem to work, except for Scratch and Etoys. Maybe you > can understand better what is happening here ? Confirmed. By replacing the files now scim-anthy works even with isolation enabled. (my locale setting is ja_JP.utf8 in ~/.i18n and envrionment variable) while IME still can't be activated for Etoys and Scratch. Both are using (basically same) Linux Squeak VM so root cause of the problem would be same... I will discuss with Etoys folks about this... Thanks, /Korakurider > > Thanks, > Sayamindu > > > > -- > Sayamindu Dasgupta > [http://sayamindu.randomink.org/ramblings] > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: InputMethod doesn't work with Rainbow activity isolation
On Sat, Nov 1, 2008 at 9:08 AM, Korakurider <[EMAIL PROTECTED]> wrote:
> Hi.
>
> I have difficulty to make Japanese input method (SCIM-anthy) work on 8.2-767.
> Input method can't be activated on activity window even if hit
> Ctrl-Space (IME on/off switch).
> After some experiment I found that IME can be activated if activity
> isolation is disabled.
> If isolation is enabled, I can activate IME only in terminal activity.
> Any clue to make it work even with isolation?
>
> Sayamindu,
> Just a quick report though ...
> I also tested ibus-anthy.
> Now installation is straightforward with yum.
> While it is also affected by isolation, I can activate it and input
> Japanese string
> into activity window.
>
Could you replace the attached files in your XO (/usr/bin/olpc-session
and /usr/lib/python2.5/site-packages/rainbow/service.py) and test ?
(ideally rainbow should be enabled)
I tested with scim-anthy, and it works for me (to be on the safe side,
edit ~/.i18n and set it to en_US.UTF-8)
All activities seem to work, except for Scratch and Etoys. Maybe you
can understand better what is happening here ?
Thanks,
Sayamindu
--
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]
olpc-session
Description: Binary data
import os
from signal import SIGCHLD
from time import time
import gobject
import dbus
import dbus.service
import dbus.bus
import dbus.mainloop.glib
from rainbow import util, inject, permissions
from rainbow.util.linux.clone import clone, CLONE_NEWNS
from rainbow.gc import gc_spool
SPOOL = '/home/olpc/isolation/1'
def log(msg, *args):
if len(args):
print msg % args
else:
print msg
class Rainbow(dbus.service.Object):
"""The Rainbow security service."""
SERVICE_NAME = 'org.laptop.security.Rainbow'
INTERFACE_NAME = 'org.laptop.security.Rainbow'
def __init__(self, bus_or_name):
dbus.service.Object.__init__(self, bus_or_name, '/')
self.preloader_hint = True
self.preload_common_modules()
def _get_lang(self):
first_line = open('/home/olpc/.i18n').readline()
name, value = first_line.strip().split('=')
value = value.strip('"')
assert name == 'LANG'
# See NOTES -- "Security risks in preforking."
assert len(value) < 64 and all(s.isalnum() or s in "[EMAIL PROTECTED]" for s in value)
return value
def preload_common_modules(self):
# Import-time logic is quite sensitive to environment variables.
os.environ['XAUTHORITY'] = inject._XAUTHORITY
os.environ['ICEAUTHORITY'] = inject._ICEAUTHORITY
# Are we never going to want to launch python activities attached to other
# displays?
os.environ['DISPLAY'] = ':0'
os.environ['GTK2_RC_FILES'] = '/usr/share/sugar/data/sugar-xo.gtkrc'
os.environ['XMODIFIERS'] = '@im=SCIM'
os.environ['GTK_IM_MODULE'] = 'xim'
os.environ['USE_XOPENIM'] = 't'
# There are all sorts of reasons why we might be unable to read a
# language setting. _get_lang()'s job is to make sure that all of them
# are represented as exceptions.
try: os.environ['LANG'] = self._get_lang()
except: util.trace()
imports = ('dbus.service',
'dbus.decorators',
'telepathy',
'sugar.activity.activity',
'sugar.activity.activityservice',
'sugar.graphics.style',
'sugar.graphics.window',
)
start_time = time()
for module in imports:
try:
__import__(module)
except:
print 'Exception when preloading module: %s' % module
self.preloader_hint = False
util.trace()
break
if self.preloader_hint:
try:
import gtk
display = gtk.gdk.display_get_default()
display.close() # This needs to happen after importing s.g.style
except:
print 'Exception when preloading module: gtk'
self.preloader_hint = False
util.trace()
print 'Module preloading took %f seconds.' % (time() - start_time)
@dbus.service.method(INTERFACE_NAME,
in_signature='s')
def ChangeActivity(self, activity_id):
"""Sets CPU throttling on the foreground and background activities as needed."""
pass
@dbus.service.met
Re: InputMethod doesn't work with Rainbow activity isolation
Wow - what a coincidence - I have been working on the same thing for the past one week :-D I think I got the m17n input methods working - I'll check if SCIM anthy works or not. Thanks, Sayamindu On Sat, Nov 1, 2008 at 9:08 AM, Korakurider <[EMAIL PROTECTED]> wrote: > Hi. > > I have difficulty to make Japanese input method (SCIM-anthy) work on 8.2-767. > Input method can't be activated on activity window even if hit > Ctrl-Space (IME on/off switch). > After some experiment I found that IME can be activated if activity > isolation is disabled. > If isolation is enabled, I can activate IME only in terminal activity. > Any clue to make it work even with isolation? > > Sayamindu, > Just a quick report though ... > I also tested ibus-anthy. > Now installation is straightforward with yum. > While it is also affected by isolation, I can activate it and input > Japanese string > into activity window. > > Thanks, > /Korakurider > -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
InputMethod doesn't work with Rainbow activity isolation
Hi. I have difficulty to make Japanese input method (SCIM-anthy) work on 8.2-767. Input method can't be activated on activity window even if hit Ctrl-Space (IME on/off switch). After some experiment I found that IME can be activated if activity isolation is disabled. If isolation is enabled, I can activate IME only in terminal activity. Any clue to make it work even with isolation? Sayamindu, Just a quick report though ... I also tested ibus-anthy. Now installation is straightforward with yum. While it is also affected by isolation, I can activate it and input Japanese string into activity window. Thanks, /Korakurider ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Serious -- Bug in Wiki-browse/Rainbow in gg-767-4
Hi, > 1.) imaged a machine using the salute method via usb to gg-767-4. > 2.) Launch wiki-browse > 3.) Click on 'technology' category link (this link important?) > 4.) hangs and/or popup window complaining about a Rainbow Policy > Issue. > 5.) Close and reopen > 6.) Rainbow Policy Issue window comes back up. > I grabbed another machine and attempted the activity again and got > roughly the same result. > Did we test this on secured machines? What's the issue here? This > is pretty fantastic considering we spent so much of our disk size > for the activity. I just did a secure reflash to 767 and tried these steps, and the activity worked -- the Technology page rendered fine. Subsequent launches raised a Rainbow dialog but didn't stop the activity from working (which we already knew about). Is there something your instructions fail to mention, such as having another Browse window open at the same time? - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Serious -- Bug in Wiki-browse/Rainbow in gg-767-4
Seth Woodworth wrote: > http://dev.laptop.org/ticket/8814 > > This is a pretty big deal. > > 1.) imaged a machine using the salute method via usb to gg-767-4. > > 2.) Launch wiki-browse > > 3.) Click on 'technology' category link (this link important?) > > 4.) hangs and/or popup window complaining about a Rainbow Policy Issue. > > 5.) Close and reopen > > 6.) Rainbow Policy Issue window comes back up. > > I grabbed another machine and attempted the activity again and got roughly > the same result. > > Did we test this on secured machines? What's the issue here? This is pretty > fantastic considering we spent so much of our disk size for the activity. > --Seth Some information is as well in 8377. Regards, Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Serious -- Bug in Wiki-browse/Rainbow in gg-767-4
http://dev.laptop.org/ticket/8814 This is a pretty big deal. 1.) imaged a machine using the salute method via usb to gg-767-4. 2.) Launch wiki-browse 3.) Click on 'technology' category link (this link important?) 4.) hangs and/or popup window complaining about a Rainbow Policy Issue. 5.) Close and reopen 6.) Rainbow Policy Issue window comes back up. I grabbed another machine and attempted the activity again and got roughly the same result. Did we test this on secured machines? What's the issue here? This is pretty fantastic considering we spent so much of our disk size for the activity. --Seth ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Rainbow-daemon dialog in Browse?
Bert Freudenberg wrote: > I've never seen a "rainbow-daemon" dialog before, what is it supposed > to do? It doesn't work anyway, I filed a ticket with screenshot: > > http://dev.laptop.org/ticket/8435 I filed http://dev.laptop.org/ticket/7930 about another Browse pop-up window titled "rainbow-daemon". Marco commented in your bug 8435 "The title is misleading, it's caused by the fact that we preload gtk inside rainbow." Is that also why `ps ax` shows "python /usr/sbin/rainbow-daemon" as the COMMAND string for Browse? `xlsclients -l` also shows "rainbow-daemon" and some "sugar-activity", but I couldn't figure out the rest of its info. -- =S user:skierpage ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Rainbow-daemon dialog in Browse?
I've never seen a "rainbow-daemon" dialog before, what is it supposed to do? It doesn't work anyway, I filed a ticket with screenshot: http://dev.laptop.org/ticket/8435 - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Problems switching back from joyride-2290 to Update.1-708 (rainbow). Help wanted.
On Thu, Aug 21, 2008 at 12:24 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > The other change we could consider would be to rev the isolation spool > version number from 1 to 2 in Rainbow and in the Datastore. There is a > small risk that other people might have hardcoded the > '/home/olpc/isolation/1' path but this should be controllable via rgrep. That seems like that's what you've been adding version numbers for, so let's do it. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Problems switching back from joyride-2290 to Update.1-708 (rainbow). Help wanted.
On Thu, Aug 21, 2008 at 10:59:13AM -0400, C. Scott Ananian wrote: >Hmm, this sounds like it should be (a) a release note, and (b) we >should post a script to 'make things right'. (Similar to the >datastore issue.) I'll stub out appropriate text in the wiki for >this. The other change we could consider would be to rev the isolation spool version number from 1 to 2 in Rainbow and in the Datastore. There is a small risk that other people might have hardcoded the '/home/olpc/isolation/1' path but this should be controllable via rgrep. Thoughts? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Problems switching back from joyride-2290 to Update.1-708 (rainbow). Help wanted.
C. Scott Ananian wrote: > On Thu, Aug 14, 2008 at 10:46 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > >> On Thu, Aug 14, 2008 at 10:16:01PM -0400, Ton van Overbeek wrote: >> >>> For my testing for trac #7788 I want to switch from Update.1 to >>> joyride-2298 and vice versa >>> (using alternate boot). >>> After switching back from joyride-2298 to Update.1 most activities do >>> not start because >>> their home directory does not exist. >>> I need some pointers where to look in rainbow how to get this two way >>> switching working. >>> Anything I can run in Update.1 or rpm to update to get this working ??? >>> One thing I noticed is that /etc/group does not have all the groupids in >>> Update.1 >>> but I have no idea how they got there in the first place. >>> Pointers to rainbow docs and rainbow changes between Update.1 and recent >>> joyrides appreciated. >>> >> Rainbow docs are sadly out of date. *hangs head in shame*. >> >> What's available is located at >> >> http://wiki.laptop.org/go/Taste_the_Rainbow >> >> and in various text files in the rainbow directory of the >> >> http://dev.laptop.org/git/security >> >> repository. >> >> The commit which broke things is almost certainly >> >> >> http://dev.laptop.org/git?p=security;a=commit;h=8fc1e8c3a7a67364f43741461f66b302d1697410 >> >> Let me know if you have further questions and I'll do what I can to be >> responsive. Other people you should consider poking include >> patchvonbraun, coderanger, homunq, and tomeu. >> > > Hmm, this sounds like it should be (a) a release note, and (b) we > should post a script to 'make things right'. (Similar to the > datastore issue.) I'll stub out appropriate text in the wiki for > this. > --scott > In case you did not notice it (yet), see trac #8016 which covers this. Ton van Overbeek ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Problems switching back from joyride-2290 to Update.1-708 (rainbow). Help wanted.
On Thu, Aug 14, 2008 at 10:46 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > On Thu, Aug 14, 2008 at 10:16:01PM -0400, Ton van Overbeek wrote: >>For my testing for trac #7788 I want to switch from Update.1 to >>joyride-2298 and vice versa >>(using alternate boot). >>After switching back from joyride-2298 to Update.1 most activities do >>not start because >>their home directory does not exist. >>I need some pointers where to look in rainbow how to get this two way >>switching working. >>Anything I can run in Update.1 or rpm to update to get this working ??? >>One thing I noticed is that /etc/group does not have all the groupids in >>Update.1 >>but I have no idea how they got there in the first place. >>Pointers to rainbow docs and rainbow changes between Update.1 and recent >>joyrides appreciated. > > Rainbow docs are sadly out of date. *hangs head in shame*. > > What's available is located at > > http://wiki.laptop.org/go/Taste_the_Rainbow > > and in various text files in the rainbow directory of the > > http://dev.laptop.org/git/security > > repository. > > The commit which broke things is almost certainly > > > http://dev.laptop.org/git?p=security;a=commit;h=8fc1e8c3a7a67364f43741461f66b302d1697410 > > Let me know if you have further questions and I'll do what I can to be > responsive. Other people you should consider poking include > patchvonbraun, coderanger, homunq, and tomeu. Hmm, this sounds like it should be (a) a release note, and (b) we should post a script to 'make things right'. (Similar to the datastore issue.) I'll stub out appropriate text in the wiki for this. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Problems switching back from joyride-2290 to Update.1-708 (rainbow). Help wanted.
On Fri, Aug 15, 2008 at 2:16 PM, Ton van Overbeek <[EMAIL PROTECTED]> wrote: > For my testing for trac #7788 I want to switch from Update.1 to > joyride-2298 and vice versa > (using alternate boot). > After switching back from joyride-2298 to Update.1 most activities do > not start because > their home directory does not exist. Besides the rainbow issues, I think that the Datastore storage has incompatible change. When you upgrade, the new datastore upgrades to a new storage format. When youdowngrade, the old datastore doesn't understand it so it moves .sugar/default/datastore aside and begins from scratch. This was discussed earlier in the list - look into .sugar/default for "backup" datastore directories if this hits you. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
I don't think we want to pick up maintenance of this kernel patch... - Jim On Sat, 2008-08-16 at 18:32 -0400, Benjamin M. Schwartz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > victor wrote: > | Is that documented? I don't see it in man page. I can try it, if > | I have a code example (says there it does not take a priority > | value, so is it just a matter of setting the policy?) > > Unfortunately, SCHED_ISO is only available in a patch by Con Kolivas, the > latest version of which is for 2.6.22. It seems that no one has attempted > to maintain that patch for newer kernels. Someone would have to put in > quite a bit of work to maintain it for newer kernels, though it appears > that the mainline scheduler authors would potentially like to include > SCHED_ISO functionality. > > I also noticed another new scheduler patch from just this week: > http://article.gmane.org/gmane.linux.kernel/719589 shows a new patch that > provides SCHED_SPORADIC, which appears to be a different sort of safe > real-time scheduler. I am less familiar with it, though it is drawn > directly from the POSIX spec. > > In any event, I think it is more practical to try to hunt down the > regression in the OLPC kernel than to attempt fancy real-time stuff. > Perhaps someone can assist Victor in a kernel bisection to find the change? > > - --Ben > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkinVYAACgkQUJT6e6HFtqRVFACfRyTFMqIQ3MruUcI9k8qaPJot > XaAAmQEWXXAK7ZGBsUK1krwoQ3glbusI > =NnsJ > -END PGP SIGNATURE- > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel -- Jim Gettys <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Problems switching back from joyride-2290 to Update.1-708 (rainbow). Help wanted.
Michael Stone wrote: > On Thu, Aug 14, 2008 at 10:16:01PM -0400, Ton van Overbeek wrote: >> For my testing for trac #7788 I want to switch from Update.1 to >> joyride-2298 and vice versa >> (using alternate boot). >> After switching back from joyride-2298 to Update.1 most activities do >> not start because >> their home directory does not exist. >> I need some pointers where to look in rainbow how to get this two way >> switching working. >> Anything I can run in Update.1 or rpm to update to get this working ??? >> One thing I noticed is that /etc/group does not have all the groupids >> in Update.1 >> but I have no idea how they got there in the first place. >> Pointers to rainbow docs and rainbow changes between Update.1 and >> recent joyrides appreciated. > > Rainbow docs are sadly out of date. *hangs head in shame*. > > What's available is located at > > http://wiki.laptop.org/go/Taste_the_Rainbow > > and in various text files in the rainbow directory of the > http://dev.laptop.org/git/security > > repository. > > The commit which broke things is almost certainly > > http://dev.laptop.org/git?p=security;a=commit;h=8fc1e8c3a7a67364f43741461f66b302d1697410 > > > > Let me know if you have further questions and I'll do what I can to be > responsive. Other people you should consider poking include > patchvonbraun, coderanger, homunq, and tomeu. > > Regards, > > Michael Just filed trac #8016 about this. Turns out the problem exists both ways 8.1->8.2 and 8.2->8.1. Ton ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 victor wrote: | Is that documented? I don't see it in man page. I can try it, if | I have a code example (says there it does not take a priority | value, so is it just a matter of setting the policy?) Unfortunately, SCHED_ISO is only available in a patch by Con Kolivas, the latest version of which is for 2.6.22. It seems that no one has attempted to maintain that patch for newer kernels. Someone would have to put in quite a bit of work to maintain it for newer kernels, though it appears that the mainline scheduler authors would potentially like to include SCHED_ISO functionality. I also noticed another new scheduler patch from just this week: http://article.gmane.org/gmane.linux.kernel/719589 shows a new patch that provides SCHED_SPORADIC, which appears to be a different sort of safe real-time scheduler. I am less familiar with it, though it is drawn directly from the POSIX spec. In any event, I think it is more practical to try to hunt down the regression in the OLPC kernel than to attempt fancy real-time stuff. Perhaps someone can assist Victor in a kernel bisection to find the change? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkinVYAACgkQUJT6e6HFtqRVFACfRyTFMqIQ3MruUcI9k8qaPJot XaAAmQEWXXAK7ZGBsUK1krwoQ3glbusI =NnsJ -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
Ok; My suggestion would then be for us to test allowing RTPRIO to 99 (the max value), if possible, so we can test its impact. Then it will be possible to test lower priorities to see what would be a reasonable limit. There has also been a question of testing stronger RT kernel patches in future releases. If so, the whole thing will need to be reconsidered then. Our problem at the moment is that the current kernel has taken a step backwards in RT performance, which we are trying to address. Maybe this will not be the case in the future. In any case, thanks for helping us sort this one out, I am actually very pleased that we can discuss the XO's RT performance. In fact, if we tune this right, we will place the OS (and the laptop) in a position of advantage against its competitors in relation to media applications. Victor - Original Message - From: "Michael Stone" <[EMAIL PROTECTED]> To: "victor" <[EMAIL PROTECTED]> Cc: "Jim Gettys" <[EMAIL PROTECTED]>; Sent: Saturday, August 16, 2008 10:39 PM Subject: Re: rainbow and pam > On Sat, Aug 16, 2008 at 10:15:08PM +0100, victor wrote: >> Aren't these priorities the same ones set in /etc/security/limits.conf? >> Or are they set by other means? > > /etc/security/limits.conf is simply one vehicle (specifically, the one > used by PAM) for getting a uid-0 process (hence a process w/ > CAP_SYS_RESOURCE) like login or su to call setrlimit() before running > some user-supplied code. Rainbow can accomplish this directly. > > Michael > > (I am interested in arguments as to whether Rainbow should be made to > interact with PAM and the 'login'/'session'/'terminal' concept cluster, > but I haven't yet gotten around to detailed investigation.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
On Sat, Aug 16, 2008 at 10:15:08PM +0100, victor wrote: > Aren't these priorities the same ones set in /etc/security/limits.conf? > Or are they set by other means? /etc/security/limits.conf is simply one vehicle (specifically, the one used by PAM) for getting a uid-0 process (hence a process w/ CAP_SYS_RESOURCE) like login or su to call setrlimit() before running some user-supplied code. Rainbow can accomplish this directly. Michael (I am interested in arguments as to whether Rainbow should be made to interact with PAM and the 'login'/'session'/'terminal' concept cluster, but I haven't yet gotten around to detailed investigation.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
Is that documented? I don't see it in man page. I can try it, if I have a code example (says there it does not take a priority value, so is it just a matter of setting the policy?) Victor - Original Message - From: "Benjamin M. Schwartz" <[EMAIL PROTECTED]> To: "Michael Stone" <[EMAIL PROTECTED]> Cc: "victor" <[EMAIL PROTECTED]>; Sent: Saturday, August 16, 2008 10:27 PM Subject: Re: rainbow and pam > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Michael Stone wrote: > | According to "man sched_setscheduler" you want either CAP_SYS_NICE or a > | non-zero RLIMIT_RTPRIO and giving these to you means that you can > | hardlock the machine anytime by busywaiting. > > As noted in a conversation with Michael, there is a potential "third way", > in the form of SCHED_ISO, isochronous scheduling. This scheduler patch > creates a "pseudo-realtime" mode that provides lower latencies without the > potential for hardlocks. > > http://ck.wikia.com/wiki/SchedulingPolicies#SCHED_ISO > > - --Ben > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkinRlsACgkQUJT6e6HFtqTEKwCeOFhU5oxlXnZHH/+GJCD6gsK5 > nyIAn1dozdz/77DzP4fv7EoXOunuzYJe > =jeiR > -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Stone wrote: | According to "man sched_setscheduler" you want either CAP_SYS_NICE or a | non-zero RLIMIT_RTPRIO and giving these to you means that you can | hardlock the machine anytime by busywaiting. As noted in a conversation with Michael, there is a potential "third way", in the form of SCHED_ISO, isochronous scheduling. This scheduler patch creates a "pseudo-realtime" mode that provides lower latencies without the potential for hardlocks. http://ck.wikia.com/wiki/SchedulingPolicies#SCHED_ISO - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkinRlsACgkQUJT6e6HFtqTEKwCeOFhU5oxlXnZHH/+GJCD6gsK5 nyIAn1dozdz/77DzP4fv7EoXOunuzYJe =jeiR -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
Aren't these priorities the same ones set in /etc/security/limits.conf? Or are they set by other means? Victor - Original Message - From: "Michael Stone" <[EMAIL PROTECTED]> To: "victor" <[EMAIL PROTECTED]> Cc: "Jim Gettys" <[EMAIL PROTECTED]>; Sent: Saturday, August 16, 2008 8:40 PM Subject: Re: rainbow and pam > According to "man sched_setscheduler" you want either CAP_SYS_NICE or a > non-zero RLIMIT_RTPRIO and giving these to you means that you can > hardlock the machine anytime by busywaiting. Audio performance is > clearly important to us in this release -- probably more important than > stopping random malicious activities from locking the machine -- so that > means that I should probably help you out on the condition that we may > need to revise the details of our arrangements in future releases. > > Is that acceptable? > > If so, I propose simply granting all activities an RLIMIT_RTPRIO rlimit > of some made-up number... say 50? > > Anyone have better ideas? > > (Note that there is a facility for setting per-bundle rlimits that we > could probably adapt, but it's not very well tested...) > > Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
According to "man sched_setscheduler" you want either CAP_SYS_NICE or a non-zero RLIMIT_RTPRIO and giving these to you means that you can hardlock the machine anytime by busywaiting. Audio performance is clearly important to us in this release -- probably more important than stopping random malicious activities from locking the machine -- so that means that I should probably help you out on the condition that we may need to revise the details of our arrangements in future releases. Is that acceptable? If so, I propose simply granting all activities an RLIMIT_RTPRIO rlimit of some made-up number... say 50? Anyone have better ideas? (Note that there is a facility for setting per-bundle rlimits that we could probably adapt, but it's not very well tested...) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Rainbow cpu load when launching an activity?
On 16 Aug 2008, at 06:57, riccardo wrote: > Hi Gary > > On Fri, 2008-08-15 at 23:18 +0100, Gary C Martin wrote: >> Hi Michael, >> >> On 15 Aug 2008, at 21:58, Michael Stone wrote: >> >>> On Fri, Aug 15, 2008 at 07:31:28PM +0100, Gary C Martin wrote: >>>> I was curious to see (when testing in joyride-2301) that rainbow >>>> (python /usr/sbin/rainbow-daemon) seems to be the process that's >>>> eating the most CPU cycles during an activity launch. >>> >>> Well, rainbow does a little bit of work in order to make a new user, >>> then it hands over control to the activity. Since we know that >>> activity >>> launching is already slow (hence the need for the module preloading >>> hack), it's not very surprising to me to that you see it chewing CPU >>> when launching activities. >>> >>> Feel free to profile, though; I'd certainly like to know it if I'm >>> doing >>> something truly idiotic. (Or if people are using rainbow in >>> environments >>> significantly different from my own.) >> >> Thanks, OK. I'm not exactly fully clued up on profiling such >> internals >> but I'll look at instrumenting interesting points of your rainbow >> source code on a running XO, and seeing if I have something useful to >> report. Please don't let that put off anyone else more qualified from >> looking. >> > > Processes spawned by rainbow get their cmdline copied over from > rainbow's one. So I think what you are seeing is that the *launched > activity* is taking more cpu time than the journal and the shell. > > The following graph shows browse startup (pid 3612): > http://dev.laptop.org/~rlucchese/temp__browse_warm.svg Thanks for that Riccardo, looks good. From what I understand that makes a lot of sense and is likely the answer. I'll still try and have a poke at the rainbow code myself out of curiosity. --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
Sorry if I was not clear. Here is the code that currently fails
under rainbow:
/* set scheduling policy and priority */
if (priority > 0) {
p.sched_priority = priority;
if (sched_setscheduler(0, SCHED_RR, &p) != 0) {
csound->Message(csound,"csound: cannot set scheduling policy to
SCHED_RR");
}
else csound->Message(csound,"csound: setting scheduling policy to
SCHED_RR\n");
}
else {
/* nice requested */
if (setpriority(PRIO_PROCESS, 0, priority) != 0) {
csound->Message(csound,"csound: cannot set nice level to %d",
priority);
}
}
This works fine on the terminal for user olpc (given the correct
limits.conf).
Thanks
Victor
- Original Message -
From: "Michael Stone" <[EMAIL PROTECTED]>
To: "Jim Gettys" <[EMAIL PROTECTED]>
Cc: "victor" <[EMAIL PROTECTED]>;
Sent: Saturday, August 16, 2008 3:33 AM
Subject: Re: rainbow and pam
> On Fri, Aug 15, 2008 at 09:14:47PM -0400, Jim Gettys wrote:
>>Michael,
>>
>>I detect a disconnect.
>
> The disconnect is that Victor has neither explained what syscalls he
> wants to be able to make nor posted his patch to limits.conf. Until he
> does one of these things, I am unable to help him.
>
> Michael
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
But as it is, if you are playing MIDI or audio through an Activity launched by rainbow, there is no way AFAIK you can renice it. The code I am testing was set to either change scheduler priority or to renice the process. None is possible. Note that what I am proposing here would not affect you, because you will never play background music and compose with TAM TAM at the same time (or not at least now, unless you have two soundcards in the system). So as far as this discussion is concerned, your worries are unfounded. Victor - Original Message - From: "Mikus Grinbergs" <[EMAIL PROTECTED]> To: Sent: Saturday, August 16, 2008 5:51 AM Subject: Re: rainbow and pam >> Proper fix: make the kernel have a per-task inheritable upper >> limit on the real-time priority. Perhaps the existing limit >> (used for niceness) can even do the job. It's this thing: > > I almost always have multiple sessions running on my XO. If one of > those sessions provides me with background music, I don't want it to > "stutter" as I do other things with my XO. For that reason I 'nice' > the task which is feeding the audio hardware (to have priority over > all other tasks). > > So far (on recent Joyrides) this is working the way I want it -- my > audio task has a priority of -12 (that's minus !). I get concerned > when there is talk of "improving" priority handling in the XO. If > something were done that caused my background music to "stutter", I > would not hesitate to "patch" *my* system to regain uninterrupted music. > > > mikus > > ___ > 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
Re: Rainbow cpu load when launching an activity?
Hi Gary On Fri, 2008-08-15 at 23:18 +0100, Gary C Martin wrote: > Hi Michael, > > On 15 Aug 2008, at 21:58, Michael Stone wrote: > > > On Fri, Aug 15, 2008 at 07:31:28PM +0100, Gary C Martin wrote: > >> I was curious to see (when testing in joyride-2301) that rainbow > >> (python /usr/sbin/rainbow-daemon) seems to be the process that's > >> eating the most CPU cycles during an activity launch. > > > > Well, rainbow does a little bit of work in order to make a new user, > > then it hands over control to the activity. Since we know that > > activity > > launching is already slow (hence the need for the module preloading > > hack), it's not very surprising to me to that you see it chewing CPU > > when launching activities. > > > > Feel free to profile, though; I'd certainly like to know it if I'm > > doing > > something truly idiotic. (Or if people are using rainbow in > > environments > > significantly different from my own.) > > Thanks, OK. I'm not exactly fully clued up on profiling such internals > but I'll look at instrumenting interesting points of your rainbow > source code on a running XO, and seeing if I have something useful to > report. Please don't let that put off anyone else more qualified from > looking. > Processes spawned by rainbow get their cmdline copied over from rainbow's one. So I think what you are seeing is that the *launched activity* is taking more cpu time than the journal and the shell. The following graph shows browse startup (pid 3612): http://dev.laptop.org/~rlucchese/temp__browse_warm.svg riccardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
> Proper fix: make the kernel have a per-task inheritable upper > limit on the real-time priority. Perhaps the existing limit > (used for niceness) can even do the job. It's this thing: I almost always have multiple sessions running on my XO. If one of those sessions provides me with background music, I don't want it to "stutter" as I do other things with my XO. For that reason I 'nice' the task which is feeding the audio hardware (to have priority over all other tasks). So far (on recent Joyrides) this is working the way I want it -- my audio task has a priority of -12 (that's minus !). I get concerned when there is talk of "improving" priority handling in the XO. If something were done that caused my background music to "stutter", I would not hesitate to "patch" *my* system to regain uninterrupted music. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
Jim Gettys writes: > Victor needs some way to be able to set the real time features > of Linux; this is certainly desirable in various audio, voip > and similar applications. Quick fix: eliminate the restriction in the kernel While this causes obvious problems for shared multi-user machines, it doesn't really cause problems for the laptop. Activities that abuse the ability, and thus force the user to reboot via power loss, will naturally be unpopular. Proper fix: make the kernel have a per-task inheritable upper limit on the real-time priority. Perhaps the existing limit (used for niceness) can even do the job. It's this thing: current->signal->rlim[RLIMIT_NICE] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
On Fri, Aug 15, 2008 at 09:14:47PM -0400, Jim Gettys wrote: >Michael, > >I detect a disconnect. The disconnect is that Victor has neither explained what syscalls he wants to be able to make nor posted his patch to limits.conf. Until he does one of these things, I am unable to help him. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
Michael, I detect a disconnect. Victor needs some way to be able to set the real time features of Linux; this is certainly desirable in various audio, voip and similar applications. Victor has been using the facilities in limits.conf to enable particular user's accounts to do this under linux. It seems reasonable to me that Rainbow should provide a way for a bundle to declare such needs - Jim On Fri, 2008-08-15 at 19:00 -0400, Michael Stone wrote: > On Fri, Aug 15, 2008 at 11:52:59PM +0100, victor wrote: > >I'm trying to get my head round how rainbow works and there is one > >thing I cannot figure out. Why is that the UIDs generated by rainbow > >do not have the same resource access privileges as other UIDs as > >set in limits.conf for pam? If I use a wildcard to match all users, > >the UIDs set by rainbow are not caught by it. > > Probably because rainbow simply calls setgroups(), setgid(), and > setuid() in order to change credentials. What would you like it to be > doing? > > Michael > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel -- Jim Gettys <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
Thanks; You have been copied into this already: http://dev.laptop.org/ticket/7603 I'm just exploring possibilities for getting better RT performance for audio on the XO. I got stuck when I could not test set the scheduler priority from an Activity (but was able to do it from the terminal). Victor - Original Message - From: "Michael Stone" <[EMAIL PROTECTED]> To: "victor" <[EMAIL PROTECTED]> Cc: Sent: Saturday, August 16, 2008 12:00 AM Subject: Re: rainbow and pam > On Fri, Aug 15, 2008 at 11:52:59PM +0100, victor wrote: >>I'm trying to get my head round how rainbow works and there is one >>thing I cannot figure out. Why is that the UIDs generated by rainbow >>do not have the same resource access privileges as other UIDs as >>set in limits.conf for pam? If I use a wildcard to match all users, >>the UIDs set by rainbow are not caught by it. > > Probably because rainbow simply calls setgroups(), setgid(), and > setuid() in order to change credentials. What would you like it to be > doing? > > Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
Thanks; You have been copied into this already: http://dev.laptop.org/ticket/7603 I'm just exploring possibilities for getting better RT performance for audio on the XO. I got stuck when I could not test set the scheduler priority from an Activity (but was able to do it from the terminal). Victor - Original Message - From: "Michael Stone" <[EMAIL PROTECTED]> To: "victor" <[EMAIL PROTECTED]> Cc: Sent: Saturday, August 16, 2008 12:00 AM Subject: Re: rainbow and pam > On Fri, Aug 15, 2008 at 11:52:59PM +0100, victor wrote: >>I'm trying to get my head round how rainbow works and there is one >>thing I cannot figure out. Why is that the UIDs generated by rainbow >>do not have the same resource access privileges as other UIDs as >>set in limits.conf for pam? If I use a wildcard to match all users, >>the UIDs set by rainbow are not caught by it. > > Probably because rainbow simply calls setgroups(), setgid(), and > setuid() in order to change credentials. What would you like it to be > doing? > > Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rainbow and pam
On Fri, Aug 15, 2008 at 11:52:59PM +0100, victor wrote: >I'm trying to get my head round how rainbow works and there is one >thing I cannot figure out. Why is that the UIDs generated by rainbow >do not have the same resource access privileges as other UIDs as >set in limits.conf for pam? If I use a wildcard to match all users, >the UIDs set by rainbow are not caught by it. Probably because rainbow simply calls setgroups(), setgid(), and setuid() in order to change credentials. What would you like it to be doing? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
rainbow and pam
I'm trying to get my head round how rainbow works and there is one thing I cannot figure out. Why is that the UIDs generated by rainbow do not have the same resource access privileges as other UIDs as set in limits.conf for pam? If I use a wildcard to match all users, the UIDs set by rainbow are not caught by it. Any clues very much appreciated Victor ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Rainbow cpu load when launching an activity?
Hi Michael, On 15 Aug 2008, at 21:58, Michael Stone wrote: > On Fri, Aug 15, 2008 at 07:31:28PM +0100, Gary C Martin wrote: >> I was curious to see (when testing in joyride-2301) that rainbow >> (python /usr/sbin/rainbow-daemon) seems to be the process that's >> eating the most CPU cycles during an activity launch. > > Well, rainbow does a little bit of work in order to make a new user, > then it hands over control to the activity. Since we know that > activity > launching is already slow (hence the need for the module preloading > hack), it's not very surprising to me to that you see it chewing CPU > when launching activities. > > Feel free to profile, though; I'd certainly like to know it if I'm > doing > something truly idiotic. (Or if people are using rainbow in > environments > significantly different from my own.) Thanks, OK. I'm not exactly fully clued up on profiling such internals but I'll look at instrumenting interesting points of your rainbow source code on a running XO, and seeing if I have something useful to report. Please don't let that put off anyone else more qualified from looking. --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Rainbow cpu load when launching an activity?
On Fri, Aug 15, 2008 at 07:31:28PM +0100, Gary C Martin wrote: >I was curious to see (when testing in joyride-2301) that rainbow >(python /usr/sbin/rainbow-daemon) seems to be the process that's >eating the most CPU cycles during an activity launch. Well, rainbow does a little bit of work in order to make a new user, then it hands over control to the activity. Since we know that activity launching is already slow (hence the need for the module preloading hack), it's not very surprising to me to that you see it chewing CPU when launching activities. Feel free to profile, though; I'd certainly like to know it if I'm doing something truly idiotic. (Or if people are using rainbow in environments significantly different from my own.) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Rainbow cpu load when launching an activity?
I was curious to see (when testing in joyride-2301) that rainbow (python /usr/sbin/rainbow-daemon) seems to be the process that's eating the most CPU cycles during an activity launch. Is this related to the faster stream changes where modules are loaded early by rainbow so that later activity launches can share them (I'm hand waving a bit here without knowing all the gruesome details)? Here's some numbers from a B4 XO launching** Browse-95 (eyeballed using top -d 5, and tload -d 2, from a remote host). Other*** activity launches also show a similar pattern (like Write and Paint, Calculate, Maze): 30-70% CPU for rainbow-daemon 15-35% CPU for sugar-shell 10-15% CPU Journal ** also tested resuming from the journal but the pattern was the same. *** excluding EToys, Terminal, Log and Analyze, where the activity python instance takes the lions share of CPU cycles. Is this ticket worthy, or behaving as expected? --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Problems switching back from joyride-2290 to Update.1-708 (rainbow). Help wanted.
On Thu, Aug 14, 2008 at 10:16:01PM -0400, Ton van Overbeek wrote: >For my testing for trac #7788 I want to switch from Update.1 to >joyride-2298 and vice versa >(using alternate boot). >After switching back from joyride-2298 to Update.1 most activities do >not start because >their home directory does not exist. >I need some pointers where to look in rainbow how to get this two way >switching working. >Anything I can run in Update.1 or rpm to update to get this working ??? >One thing I noticed is that /etc/group does not have all the groupids in >Update.1 >but I have no idea how they got there in the first place. >Pointers to rainbow docs and rainbow changes between Update.1 and recent >joyrides appreciated. Rainbow docs are sadly out of date. *hangs head in shame*. What's available is located at http://wiki.laptop.org/go/Taste_the_Rainbow and in various text files in the rainbow directory of the http://dev.laptop.org/git/security repository. The commit which broke things is almost certainly http://dev.laptop.org/git?p=security;a=commit;h=8fc1e8c3a7a67364f43741461f66b302d1697410 Let me know if you have further questions and I'll do what I can to be responsive. Other people you should consider poking include patchvonbraun, coderanger, homunq, and tomeu. Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Problems switching back from joyride-2290 to Update.1-708 (rainbow). Help wanted.
For my testing for trac #7788 I want to switch from Update.1 to joyride-2298 and vice versa (using alternate boot). After switching back from joyride-2298 to Update.1 most activities do not start because their home directory does not exist. I need some pointers where to look in rainbow how to get this two way switching working. Anything I can run in Update.1 or rpm to update to get this working ??? One thing I noticed is that /etc/group does not have all the groupids in Update.1 but I have no idea how they got there in the first place. Pointers to rainbow docs and rainbow changes between Update.1 and recent joyrides appreciated. Ton van Overbeek ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
