WikipediaEN Activity does not work on secure machines with 767

[frances]

Rainbow policy issue hangs up when you load the activity. Seems to be on secure machines only. Seth reproduced it at the MIT Museum, but we don't have any logs for this yet. Any further questions should go to Seth as he observed the issue.

[isforinsects]

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.

[sj]

See also #8377 -- this seems related to having another Browse instance open at the same time.

[cjb]

isforinsects doesn't mention having another Browse instance running at the same time. Was there one?

[cjb]

I can't reproduce this.

[jgotangco]

I've upload the logs I get from Wikipedia Activity. The behavior I get is that every time I run the Activity, the Rainbow daemon prompt pops out but clicking OK will let you use the wikie.

[frances]

I saw this rainbow error message again when trying to open WikipediaEN after opening and closing every activity in the G1G1 activity pack (looking for another bug, the keep error issue). I got some screenshots and logs from both of the XOs that reproduced this bug, all attached.

[frances]

screenshot of rainbow error

[frances]

another screenshot of the rainbow error

[frances]

log of wikipediaEN rainbow error

[frances]

possibly incomplete log of wikipediaEN rainbow error

[frances]

possibly the complete log (similar to incomplete log) or wikipediaEN rainbow error

[mstone-xmlrpc]

Pushing out to 9.1.0, per edmcnierney's request.

[thomaswamm]

I saw this problem when testing 8.2.1 candidate build-800 on a G1G1v1 XO with a developer key. Same Rainbow error message dialog box as seen by Frances. When I clicked on Okay, I could use the activity. A later time, I did not get the error message when launching Wikipedia activity. Yet another time, I got the Rainbow error again, then clicked the upper right 'x' to close the dialog box, but then the activity did not start.

[sj]

Thomas's comments are the most troubling - the variation in behavior. Claudia is now encountering a similar problem on a Spanish machine running 802 with security turned off (dev key installed), and with no other browsers running.

After seeing this error message: http://dev.laptop.org/attachment/ticket/8814/Screenshot%20of%20wikipedia%20activity%20rainbow-daemon%20error%20msg.png

And clicking 'OK', the activity runs fine for me, but it requires a clickthrough every time.

See #8377 for a related bug.

[mstone]

This dialog is a standard error dialog presented by xulrunner, apparently because it is unhappy with the permissions assigned to files in its profile. To debug, an interested onlooker should determine exactly why it is unhappy, for example, by locating the precise context in which this dialog is displayed in the xulrunner source code or by getting xulrunner to log more detailed error information. Then we will have a better idea of what can be done to resolve the issue.

(NB: Do not be fooled by the dialog's title bar into thinking that rainbow is active when the dialog is displayed; in fact, the title bar reads "rainbow-daemon" because the name of the process running xulrunner is, in fact, "rainbow-daemon" and the process name is "rainbow-daemon" only because of the preforking hack. In reality, by the time we get to this error message, rainbow has long since handed over control to the activity.)

(NB 2: This excerpt:

DEBUG:xpcom:Python Factory creating GlobalHistory
1226333907.073126 DEBUG xpcom: Python Factory creating GlobalHistory
ERROR:xpcom:Creation of class '<class globalhistory.GlobalHistory at 0xb50aff8c>' failed!
Exception details follow

1226333907.109287 ERROR xpcom: Creation of class '<class globalhistory.GlobalHistory at 0xb50aff8c>' failed!
Exception details follow

ERROR:xpcom:Unhandled exception calling 'int8 createInstance(in nsISomething, in nsIID &, out retval InterfaceIs *);'
Traceback (most recent call last):
  File "/usr/lib/xulrunner-1.9/python/xpcom/server/policy.py", line 277, in _CallMethod_
    return 0, func(*params)
  File "/usr/lib/xulrunner-1.9/python/xpcom/server/factory.py", line 57, in createInstance
    return self.klass()
  File "/home/olpc/Activities/Browse.activity/globalhistory.py", line 34, in __init__
    self._store = places.get_store()
  File "/home/olpc/Activities/Browse.activity/places.py", line 137, in get_store
    _store = SqliteStore()
  File "/home/olpc/Activities/Browse.activity/places.py", line 57, in __init__
    self._cleanup()
  File "/home/olpc/Activities/Browse.activity/places.py", line 129, in _cleanup
    cursor.execute('delete from places where last_visit < ?', (date,))
OperationalError: attempt to write a readonly database

seems rather suspicious to me...)

[v8media]

Checking where to submit information for this bug? Here or sugarlabs.org? We've got at least one XO doing this in Takaungu Kenya, and my newly flashed personal G1G1 from the first batch is doing the same. Mine is running build 802, Sugar 0.82.1, and the other one is as well.

As far as scenario, I got the rainbow error before being logged onto a network. Once I logged onto the network, WikipediaEN just sits there launching for a while, and then silently closes.

Let me know if a log would be useful.

Thanks, Ian

[v8media]

(Didn't mean to change the priority there, changing it back)

[cjb]

Hi,

I didn't realize this bug would inhibit launching WikiBrowse altogether; usually the dialog is harmless, in my opinion. You might want to check that no other activities are loaded at the time you launch WikiBrowse.

If it is fatal to launch, and you care more about WikiBrowse than having activity isolation, your best bet might be to disable Rainbow altogether, with:

su
rm /etc/olpc-security
reboot

in the Terminal activity.

[wadeb]

It seems strange that this issue affects WikiBrowse but not Browse.

WikipediaEN subclasses the Browse activity classes, adding certain UI elements and changing the home page.

Two possibilities:

* The system is handling the Browse activity specially; this special handling needs to be updated to include WikipediaEN. * Some aspect of Browse that is duplicated in WikipediaEN, such as activity.info, needs to be updated in WikipediaEN.

Other thoughts?

The read-only database errors definitely seem suspicious. Perhaps the profile directory is not being managed properly. What is the 'places' feature in places.py anyway?

[martin.langhoff]

Looking at this (at Peru's request). Here is what I can see on an 8.2.2 preview build (802B1)...

• rainbow keeps the same group, but does _not_ give us the same uid -- if you run Wikipedia.xo several times, you can do grep dropping\ priv org.laptop.WikipediaActivity* and you'll see the uid increasing _even if the previous run closed correctly_.
• Looking at the logs, we hit this issue in the code that opens the "places" sqlite db and attempts to remove old/stale data from it. This sqlite db is mode 644. This is not what causes the warning -- probably other xulrunner component is trying to open a file in RW mode, and failing to do so for the same reason.
• If I open Browse several times, it does *not* get new uids every time. Even if I open various concurrent sessions.

There is an odd interaction between Rainbow's uid assignment mechanism and Wikipedia.xo. I am not sure how this is handled though.

[cjb]

There's a list of activities that should always receive the same UID from rainbow, and Browse and Terminal are on the list. Sounds like Wikipedia needs to be added.

[martin.langhoff]

The fix is trivial if we want to do in on Wikipedia.xo itself -- as per http://wiki.laptop.org/go/Activity_bundles#activity.2Fpermissions.info we need to do add a permissions.info file containing constant-uid.

As cjb mentions, there is probably a whitelist of such apps. But we don't need to touch the whitelist, the activity can ask for this on its own.

[martin.langhoff]

Clean 802B1 install (includes WikipediaEN-10.xo); after opening/closing wikipedia twice (and seeing the error)...

• Just adding the permissions.info file is not enough - error persists
• Restart Sugar/X - error persists
• Reboot XO - error persists
• Prepare a "WikipediaES-11.xo" -- error persists ** steps: unpack a WikipediaES-10.xo; bump the rev number to 11, add permissions.info; mention permissions info in the MANIFEST, repack...

So the fix is good only if you have never run WikipediaES.xo before. Hmmm. There must be a way to get Rainbow to re-read the config -

[mstone]

1. Thanks for working on resolving this bug. Polish is good.

2. The fastest way to work around the problem is to change the activity's bundle id so that rainbow sees it for the first time.

3. There is no list of apps which get constant-uid; permissions.info is the approved API.

4. rainbow parses the permissions.info file every time it launches an activity.

5. My current *guess* based on your notes and a quick review of the source code is that rainbow *is* launching WikipediaES-11 as constant-uid but that the error continues to occur because the uid which is selected after constant-uid is applied is *different* from the uid that owns the files in the persistent $SAR/data directory. Log data would permit us to confirm or to reject the first half of this hypothesis. To confirm or to reject the second half, you could try nuking the contents of the $SAR/data dir. If you get a clean launch afterwards, then we've probably found the culprit.

[martin.langhoff]

What you mention in #5 is close to being the problem.

There is one thing that I find deeply intriguing... if an activity _does not_ have "constant-uid", it gets a different uid everytime, but the owner of the files in its data dir is not fixed. So the meaning of user/group permissions, from the PoV of the activities _and their libraries_ is subverted.

I emphasize the issue with libraries because I assume that the activity programmer has reasons to play nice with rainbow's quirks, but widely used libraries are much harder to move.

As for a "right fix" for this, a recursive chown has its risks. But without it, the owner bit is broken...

[martin.langhoff]

I think that the least risky approach is to leave Rainbow alone, and add an appropriate permissions.info file. This will fix things for fresh installs -- after all, the dialog (and lost functionality) are a minor annoyance, not a showstopper.

Along the way, I tried a patch for the Wikipedia activity to scan its datadir and chown or chmod anything found there that is not owned by itself. This does not work because even if you have g+rwx in the dir, you cannot chown a file or dir to yourself.

Not sure how newer versions of Rainbow handle this ownership issue, but any program that saves its state in 644 or 600 files (and many do for good reasons) will consistently run afoul of Rainbow. I do think that Rainbow should carefully chown everything in data.

I also considered changing Rainbow so that in the case of a "new constant-uid", it scans for uid ownership to try to match the "original" uid. This is not feasible however: the data dir may contain any number of uids, collected over the course of many invocations.

[martin.langhoff]

The approach in this patch fails due to posix restrictions.

[martin.langhoff]

cjb - ping? Can we get an updated wikipediaES for Perú, Uy, others...?

[cjb]

Done: http://dev.laptop.org/~cjb/eswiki/Wikipedia-11.xo

Would you mind testing it before I release properly?

[godiard]

This ticket is not longer relevant.