Changes
Jump to navigation
Jump to search
Line 70:
Line 70: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Running Linux Applications Under Sugar (view source)
Revision as of 21:39, 13 July 2008
, 21:39, 13 July 2008→Comments
===Comments===
===Comments===
I haven't been able to get this to work in Update.1 --[[leetcharmer]]
I haven't been able to get this to work in Update.1 --[[leetcharmer]]
Rob - I modified the script to work in Update 1 for SeaMonkey, but it requires an effective disabling of security. The crux of the problem is that Rainbow runs your application as a totally new user each time (never as "olpc"), and that these "on-the-fly" users don't have write access to their home directories. All of these users are created in the same persistent group, and all share write access to a common "data" directory for the group. (The preceding is just a paraphrase of the Rainbow docs - should likely be a link). In the case of non-Sugar apps, the application has no idea that the usual role of a user has been migrated to a group, and so the application is unlikely to create it's data files with the correct permissions.
'''Note Well:''' ''The following instructions essentially remove all security on your machine. If you have set passwords on any of the machine accounts (root, olpc, etc.), likely you don't want to execute these instructions.''
<pre>
[olpc@xo ~]$ su
[olpc@xo ~]# chmod a+s /bin/chmod
</pre>
These lines allow any user to change permissions on any file and/or directory in the system. Therefore, having something only readable / executable by root is no longer a protection, since an unprivileged user can just change the permissions. In my case, I couldn't lose what I didn't have -- I have no password for the root or olpc users, so there was no effective change.
In general sudo would be a more graceful approach to this problem, but I couldn't get it to work in a script (first, you need to allow all uids > 10000; second, you need it to not prompt for a password; and third, su can't be invoked from a Sugar script because stdin is not a tty, even if no password is required).
After using the above to allow the Rainbow "on-the-fly" users to change permissions on files they don't own, we use the chmod ability in the script. The following script is just CatMoran's script with a few lines added at the beginning. Any other minor formatting changes are accidental and a result of my editing the file 100 times to try to find out why it wasn't working. I've only tested this script with SeaMonkey -- but I think similar ideas would work for other applications.
<pre>
#!/bin/sh
# Causes SeaMonkey to put the .mozilla directory in a
# place that is writable, and also where Rainbow wants
# it.
export HOME="$SUGAR_ACTIVITY_ROOT/data"
# libgnomevfs ignores the HOME environment variable,
# so make our actual home directory writable for the
# .gnome2 and .gnome2_private directories.
chmod g+w $SUGAR_ACTIVITY_ROOT
# SeaMonkey ignores umask and makes everything
# only user-accessible. But, we're running as
# a different user each time. So make everything
# in HOME group-accessible (at a minimum, make
# .mozilla and everything in it group-accessible).
chmod -R g+rwx $SUGAR_ACTIVITY_ROOT/data/.*
chmod -R g+rwx $SUGAR_ACTIVITY_ROOT/data/*
while [ -n "$2" ] ; do
case "$1" in
-b | --bundle-id) export SUGAR_BUNDLE_ID="$2" ;;
-a | --activity-id) export SUGAR_ACTIVITY_ID="$2" ;;
-o | --object-id) export SUGAR_OBJECT_ID="$2" ;;
-u | --uri) export SUGAR_URI="$2" ;;
*) echo unknown argument $1 $2 ;;
esac
shift;shift
done
export LD_PRELOAD="$SUGAR_BUNDLE_PATH/lib/libsugarize.so"
export NET_WM_NAME="SeaMonkey"
exec /usr/bin/seamonkey
</pre>