[OLPC Security] Shutting down fds prior to execvpe in rainbow/inject.py: joyride 247 under Qemu

[Marcus Leech]

Michael et al:

I just uploaded the EXT3 image for Joyride 247, and it seems to mostly work.

I experimentally put some code just before the execvpe() in inject.py to
close FDs >= 3 and <= 10. I picked 10 out of the
air, but I wouldn't expect there to be many open file descriptors at
that point. Actually, given the semantics of dup(),
you could use it to probe what the maximum FD number is just before
execvpe(), so the terminating condition could
be something like <= dup(0).

Anyway everything appears to be sane after the experiment (that is to
say, nothing is any *more* broken after this
compared to before this).

I note that Clock doesn't work at all (Stays in "Starting..." forever),
and eToys comes up, but bits of it fail with error dialogs, and
then there's no way to get out of it, or return to the Sugar
desktop--I had to go over to the virtual serial console and kill -1 it.
Logviewer hangs just like Clock. So does MaMa Media Creative Center,
and Record. Hmmm.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.laptop.org/pipermail/security/attachments/20071106/6b5569bf/attachment-0001.pgp

[Michael Stone]

Post by Marcus Leech
I experimentally put some code just before the execvpe() in inject.py to
close FDs >= 3 and <= 10. I picked 10 out of the
air, but I wouldn't expect there to be many open file descriptors at
that point. Actually, given the semantics of dup(),
you could use it to probe what the maximum FD number is just before
execvpe(), so the terminating condition could
be something like <= dup(0).

Thanks for trying this. You should make yourself a clone of the security
repo at

users/mleech/security

and I'll start pulling from you.

Post by Marcus Leech
Anyway everything appears to be sane after the experiment (that is to
say, nothing is any *more* broken after this
compared to before this).
I note that Clock doesn't work at all (Stays in "Starting..." forever),

If you look at /home/olpc/.sugar/default/logs/shell.log you'll see that
Clock is crashing during startup trying to find 'clock.svg'.

Post by Marcus Leech
and eToys comes up, but bits of it fail with error dialogs, and
then there's no way to get out of it,

I reported at least one part of this problem to Bert a day or two ago.
Just filed a ticket for it (#4703). We'll see if there are other
problems besides Etoys trying to create $SAR/sandbox.

Post by Marcus Leech
or return to the Sugar desktop--I had to go over to the virtual serial
console and kill -1 it.

Yeah, this is a combination of a rainbow bug and a sugar bug. The
rainbow bug is that we aren't reporting the pid of the process we've
started for Rainbow to wait on.

The Sugar bug is that there's no way to remove the icon of an activity
that crashed during startup.

Post by Marcus Leech
Logviewer hangs just like Clock. So does MaMa Media Creative Center,
and Record. Hmmm.

Record has been crashing on startup for a long time (a week?) because
it's trying to mkdir() a directory that already exists.

MaMa Media Creative Center had a similar problem, though some of the
other MaMaMedia activities started fine (e.g. Joke Machine).

I'm not yet sure what's up with LogViewer.

Thanks for the comprehensive report!

Michael

[Bert Freudenberg]

Post by Michael Stone

Post by Marcus Leech
I note that Clock doesn't work at all (Stays in "Starting..." forever),

If you look at /home/olpc/.sugar/default/logs/shell.log you'll see that
Clock is crashing during startup trying to find 'clock.svg'.

Heads up to Activity developers: this is because Activities can no
longer
assume that they are started in the $SUGAR_BUNDLE_PATH directory.

Ugh. Why? The reason for having $SUGAR_BUNDLE_PATH be the Activity's
cwd is to make it easy for developers to access resources in the
bundle with relative path names. Why would that need to change under
rainbow?!

- Bert -

[Michael Stone]

Bert,

It doesn't _have_ to change; if people generally prefer to be started in
SUGAR_BUNDLE_PATH (rather than in SUGAR_ACTIVITY_ROOT) then we can
easily accomodate them.

Is starting in SBP better, then?

Michael

Post by Bert Freudenberg

Post by Michael Stone

Post by Marcus Leech
I note that Clock doesn't work at all (Stays in "Starting..." forever),

If you look at /home/olpc/.sugar/default/logs/shell.log you'll see that
Clock is crashing during startup trying to find 'clock.svg'.

Heads up to Activity developers: this is because Activities can no
longer
assume that they are started in the $SUGAR_BUNDLE_PATH directory.

Ugh. Why? The reason for having $SUGAR_BUNDLE_PATH be the Activity's
cwd is to make it easy for developers to access resources in the
bundle with relative path names. Why would that need to change under
rainbow?!
- Bert -

[Bert Freudenberg]

Yes, SBP is better. If d.l.o was up I could point to the discussion
for this.

- Bert -

Post by Michael Stone
Bert,
It doesn't _have_ to change; if people generally prefer to be
started in
SUGAR_BUNDLE_PATH (rather than in SUGAR_ACTIVITY_ROOT) then we can
easily accomodate them.
Is starting in SBP better, then?
Michael

Post by Bert Freudenberg

Post by Michael Stone

Post by Marcus Leech
I note that Clock doesn't work at all (Stays in "Starting..." forever),

If you look at /home/olpc/.sugar/default/logs/shell.log you'll see that
Clock is crashing during startup trying to find 'clock.svg'.

Heads up to Activity developers: this is because Activities can no
longer
assume that they are started in the $SUGAR_BUNDLE_PATH directory.

Ugh. Why? The reason for having $SUGAR_BUNDLE_PATH be the Activity's
cwd is to make it easy for developers to access resources in the
bundle with relative path names. Why would that need to change under
rainbow?!
- Bert -

[Michael Stone]

Post by Bert Freudenberg
Yes, SBP is better. If d.l.o was up I could point to the discussion
for this.

Okay, this fix should appear in the next release of Rainbow, which will
probably happen later tonight.

In the mean time, you can apply the fix manually by changing the only
line in

/usr/lib/python2.5/site-packages/rainbow/inject.py

with a call to 'os.chdir()' to point to env['SUGAR_BUNDLE_PATH'] rather
than 'home'.

Michael