Can't run a application on a CD
Submitted by hig..@..mx.net
Assigned to Allison Lortie @desrt
Description
This will probably be a meta bug for all the problems found.
Short version: we need a way to create a simple file to allow users to run content from a CD-ROM (after asking permission to the user) without any other steps for distros following freedesktop specifications. Current support is not enough and it is full or problems.
Long version:
My company is building some CD with content for Windows and Mac. They have a startup.exe and a startup.app for the user to launch the program from the CD, just by inserting the CD, open it and click on the correct "icon". The application is just a script to enable flash to run on the CD and starts firefox loading local CD content.
I talked with then and manage to try adding a experimental linux support, so i build a simple startup.sh script for that. This script runs fine from the terminal. Trying to run that .sh file from various distros, using the DE file-manager i get mixed results, some run the file, other open the text file for editing.
I then tried to create a .desktop file to workaround that. Problem, the .desktop file requires a full path or that the apps is in the $PATH, but i'm running from a CD, with a unknown path to it (can be /media/cdom, /media/label from the cd/, /mnt/cd/, etc). the .desktop specification don't have any way to find the current location, requiring hacks. After many tries i found that this command in the Exec= seems to work in many places:
bash -e "$(dirname %k)/script.sh"
its a ugly hack... that i found later that don't work in all places (ie: Ubuntu) for unknown reasons, breaking the .desktop support on a CD. So first bug/feature request:
- the .desktop file should have a %l, to give the current .desktop location (equal to the %k, but without the .desktop file name), to be used to run local content from a unknown location.
I tried to add a icon to the .desktop file, but the icon is stored in the CD and we don't have any way to point to it, as ,again, the CD mount point is unknown and must be dynamically found. I can't use the normal locations because i have not install anything yet. So the second bug/feature request:
- Create a way to use a icon, using relative paths, or reusing the %l from above, to use local icons
When burned a testing CD, i found another problem. The .sh isn't executable, nor the .desktop. The CD was burned using a windows and without the rock ridge extensions (http://en.wikipedia.org/wiki/Rock_Ridge), so no unix permissions. I was told that i probably will not have that extensions due to fear of compatibility problems, possible increase costs and lack of control of the CD production process. Even with the rock ridge extensions i found that distos sometime force the permissions on the CD, or mount then with the noexec, so any solution should not rely on the unix permissions on a CD to work. Someone can also mounts the CD on a windows and try to use it on a linux, possible due the lack of the CD-ROM on the linux machine, losing the unix permissions. So again:
- Allow .desktop execution, even without execute permissions, if the mounted filesystem is read-only or lacks the execute flag (just the lack of support for it or also the noexec?). Maybe also apply this to the .autorun support.
I know that this one is dangerous and that altering the noexec flag might be problematic. Asking the user for permissions should always be required. Obeying some system flag to allow this should also be recommended (possible enforced via the noexec mount flag). Requiring some public key signature, validating the .desktop owner might increase a little the trust level.
The .sh permissions can be bypassed using something like bash script.sh, but for the .desktop permissions i known no workaround, other than copy the files to the local disk and manually change permissions.
I also tried the .autorun support, but i quickly found out that it also requires execute permissions.
Either, one should not require the user to understand unix permissions, remount the CD-ROM with different flags, nor copy files to the local hard disk (and change permissions) to enable to execute a .desktop file. Be a .autorun, a .desktop file or a new .launcher file.
The CD and the DVD might be less important today than in the past, but USB pen-drivers and SD cards might replace then for offline content, and with commercial content, they too might be read-only and using unix permissions unfriendly filesystems (fat32). In the future, new network filesystems might also be used to allow a user to access new applications and content (just look at the dropbox and google drive)
So i think we need to improve this, to allow better features parity with windows and mac. right now creating the same content CD for linux (and other unix) as in windows and mac, that works everywhere is very hard, if not impossible.
If accepted that this is a problem, i will open the 3 bugs and post then here