Ticket #5013 (new defect)

Opened 7 years ago

Last modified 7 years ago

Watch and Listen doesn't work with security enabled

Reported by: AlexL Owned by: dgilmore
Priority: high Milestone: 8.2.0 (was Update.2)
Component: security Version:
Keywords: rainbow-integration Cc: AlexL, mstone, jg
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

build Joyride 305 q2d04

I believe there is a permissions problem.

Attachments

org.osl.MediaPlayerActivity-1.log (6.2 kB) - added by AlexL 7 years ago.
wnl.log (3.5 kB) - added by kreneskyp 7 years ago.
org.osl.MediaPlayerActivity-1.2.log (14.2 kB) - added by kreneskyp 7 years ago.
joyride 339
bundle.diff (4.1 kB) - added by marco 7 years ago.

Change History

Changed 7 years ago by AlexL

  Changed 7 years ago by jg

  • owner changed from jirwin to kreneskyp
  • milestone changed from Never Assigned to Update.1

  Changed 7 years ago by kreneskyp

I haven't been able to get w&l running on joyride305. also unable to find any logs on it.

The only file that watch&listen creates is a preferences file. its stored in the home directory. would that cause this issue?

  Changed 7 years ago by marco

Yep, it would. You probably want to use $SUGAR_ACTIVITY_ROOT/data to store the prefs.

follow-up: ↓ 8   Changed 7 years ago by kreneskyp

Are exceptions allowed to that rule? I believe it is not possible to change the path at runtime and would require changes within the helix engine.

It might be possible to force helix to start without the file but it would increase startup time.

  Changed 7 years ago by marco

  • cc jg added

Personally I don't think we should make exceptions for specific activities. Up to Michael and Jim though.

  Changed 7 years ago by jg

I'd like to see this fixed if at all possible...

  Changed 7 years ago by jg

My reasons is that codecs are one of the most common attack vectors, and therefore Rainbow security in fact will get us something real even in the short term....

in reply to: ↑ 4   Changed 7 years ago by mburns

Replying to kreneskyp:

Are exceptions allowed to that rule? I believe it is not possible to change the path at runtime and would require changes within the helix engine.

Unfortunately, no. Home directories are an explicitly off-limits space for writing among all activities. Using the path $SUGAR_ACTIVITY_ROOT/data to store codecs, configuration files and any other persistent data is a requirement of Rainbow.

follow-up: ↓ 13   Changed 7 years ago by bert

Workaround: Simply set $HOME to $SUGAR_ACTIVITY_ROOT/data before loading the helix engine.

  Changed 7 years ago by kreneskyp

Can you be more descriptive about "doesn't work". Did you see a crash, did the activity hang while loading, or it just didn't play the file after starting. for me it didnt play the file.

  Changed 7 years ago by AlexL

build 639 q2d04

I moved Watch and Listen 10 from a usb stick to the journal, which installed it in /home/olpc/Activities

I then tried to resume an mp3 file with it. The watch and listen icon just keeps blinking in the donut and never loads. The error in the logs is the same as the one in the log I already attached. The activity is being denied permission to the /home/olpc/Watch & Listen.activity directory. I'm guessing that a codec is needed to play the file, and it's trying to access the ones stored in the helix directory. Perhaps the file you were trying to play didn't require any of the codecs in that directory, and so the activity was able to load.

  Changed 7 years ago by kreneskyp

is read access to ~/Watch & Listen.activity/helix restricted by security? If so where can the files be moved?

in reply to: ↑ 9 ; follow-up: ↓ 15   Changed 7 years ago by kreneskyp

Replying to bert:

Workaround: Simply set $HOME to $SUGAR_ACTIVITY_ROOT/data before loading the helix engine.

does this directory need to be created on the filesystem or is it something virtual that only exists within the cage in which the activity runs.

  Changed 7 years ago by bert

Rainbow creates it. Sugar does not. So just do a "mkdir -p" which doesn'y hurt in either case.

in reply to: ↑ 13   Changed 7 years ago by mburns

Replying to kreneskyp:

Replying to bert:

Workaround: Simply set $HOME to $SUGAR_ACTIVITY_ROOT/data before loading the helix engine.

does this directory need to be created on the filesystem or is it something virtual that only exists within the cage in which the activity runs.

To expand on bert, a little:

As part of container creation (the virtualization bubble that each activities it put into), certain files and directories are mounted into that container's unique view of the filesystem. The $SUGAR_ACTIVITY_ROOT/data, along with some log folders, etc (IIRC) are created for read/write access by that activity and no one else. On activity close, the container is 'broken down' and the changes to your $SAR/data directory, among others, are unmounted from their relative paths back to their system-wide absolute paths (which are not r/w accessible from within a container) so that they can be remounted the next time your activity is opened.

Changed 7 years ago by kreneskyp

  Changed 7 years ago by kreneskyp

attached a new log.

the activity should be placed in /usr/share/activities my understanding is that activities in this location will have access to read anything in its bundle.

I updated $HOME at runtime but there is still a problem (see log) creating a directory.

This change may fix the helix prefs file but not guaranteed as it is the 2nd method helix will try to locate the home directory with. Greg wright is working on a fix to make WnL use $HOME env var as its method for determining the home directory.

  Changed 7 years ago by kreneskyp

something in WnL is trying to create/use ~/.gnome2 and failing. modifying the $HOME property did not fix this.

Changed 7 years ago by kreneskyp

joyride 339

  Changed 7 years ago by kreneskyp

~/.gnome2 is created by something by the sugar python classes. When working properly nothing appears to be created there so failure to create the directory has no impact on WnL working. WnL should run even if the preference file cannot be created. I was able to get an mp3 to play in joyride 305. When trying to open a video there was a problem shown in wnl.log

I upgraded to joyride339. It caused new bugs. WnL crashes for all files. Attached the log from this. I was unable to make much sense of what the log is saying.

follow-up: ↓ 20   Changed 7 years ago by marco

Might be related to the & in the path/bundle id.

in reply to: ↑ 19   Changed 7 years ago by kreneskyp

Replying to marco:

Might be related to the & in the path/bundle id.

Does not appear to be the cause.

I changed the directory to "WatchAndListen" and no change. The bundle id is "org.osl.MediaPlayerActivity"

  Changed 7 years ago by tomeu

In the logs, you can see that to execvpe is passed this env var:

dbus.String(u'SUGAR_BUNDLE_NAME'): dbus.String(u'\u0627\u0644\u064a\u0648\u0645\u064a\u0627\u062a')

And the error is:

<type 'exceptions.UnicodeEncodeError'>: 'ascii' codec can't encode characters in position 0-7: ordinal not in range(128)

I see quite clear that python is choking on that env var. Who sets it to such an strange value?

Michael, is that Rainbow?

  Changed 7 years ago by marco

  • owner changed from kreneskyp to marco
  • component changed from helix-activity to sugar

The unicode string is the arabic for Journal apparently (according to translate.google.com, I don't know ar!).

Python (and so rainbow) is choking when trying to set unicode env variables with sys.defaultencoding being ascii. Gtk changes sys.defaultencoding to utf-8, so we are not seeing this in sugar. I can think of two possible options:

  1. Do not use an environment variable to pass the bundle name around. It's quite silly anyway, being in-process communication, and it will have to be fixed at some point.
  2. Run our python with default encoding utf8. Since most of our code runs with utf8 encoding (because of import gtk), that would have the advantage to make it consistent.

My feeling is that 2 is too risky right now, and since 1 is good to do anyway I think we should do 1.

Changed 7 years ago by marco

  Changed 7 years ago by marco

  • keywords review? added

  Changed 7 years ago by mstone

Another reasonable course of action is to continue passing the bundle name as an environment variable and to make Rainbow unicode-safe by explicitly setting character encodings as necessary.

  Changed 7 years ago by marco

  • keywords review? removed
  • owner changed from marco to mstone
  • component changed from sugar to security

Encoding the strings as utf8 sounds like the less invasive plan. I'll still want to get my patch in at some point, but it's not necessary for Update.1.

  Changed 7 years ago by mstone

It appears to me that the 'utf8_strings' option described in http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html#data-types gives a reasonable band-aid that will prevent us from ever seeing unicode objects sent through dbus.

  Changed 7 years ago by mstone

  • owner changed from mstone to ApprovalForUpdate

Expected to be fixed in rainbow-0.7.5-1.olpc2 which was just built and tagged into dist-olpc2 in Fedora's Koji.

To test, pick an activity, insert a unicode character into the activity's 'name' field in both 'activity/activity.info 'and the 'locale/<lang code>/activity.linfo' files and save the files with a UTF-8 character encoding. Then restart Sugar and attempt to start the modified activity. Check the Log Viewer for tracebacks.

(This file modification can be performed in vi. In insert mode, type 'v u 1234' to insert the unicode code point 0x1234 at the caret. Before writing out the changed file, be sure to run the command 'set fileencoding=utf-8'. Alternately, one could test by running activities from a localization that has non-ASCII activity names such as Arabic.)

Finally, since the rainbow packaging changed in this release, it is important that we verify that

1) /etc/olpc-security exists. 2) That rainbow is running (e.g. that 'ps auxfwww | grep rainbow' reports a rainbow-daemon instance) 3) That rainbow is set to run by default (i.e. that 'chkconfig --list rainbow' reports that rainbow is set to run in runlevels 2-5 or so)

  Changed 7 years ago by jg

  • owner changed from ApprovalForUpdate to dgilmore

Approved. Dennis; please do the requested verifications...

Note: See TracTickets for help on using tickets.