Differences of a PND residing on FAT vs ext root FS

[hmc]

Hi guys,


I don't get it.


I have a PND and want to start a script inside it.


Launching the script works, if the PND is stored on the FAT partition of my SD card.


Launching the script fails, if the PND is stored on the root FS (ext3).


What's the reason? How can I make the script work, even if the PND is stored in the root fs?


Details:


It's the keyboard layout switcher PND by slaeshjag:


http://repo.openpandora.org/?page=detail&app=change-keymap-0.1-slaeshjag


I want to control keyboard layout switching from outside, more precizely, from a configbutton plugin I am developing.


For that, I need to execute the script inside the PND's "./keymaps" directory directly, i.e. bypass the standard run script of the PND.


Hence I call from the configbutton Plugin (or from console, doesn't make a difference for this issue):

/usr/pandora/scripts/pnd_run.sh -p [PATH_TO_PND]/kblayout.pnd -e "./keymaps/German-external-qwertz" -b "kblayout"

If the PND is stored on the SD card, i.e. [PATH_TO_PND] = /media/BOOT/pandora/menu, the call succeeds.


If the PND is stored in the root fs (which is also on SD card here), i.e. [PATH_TO_PND] = /pandora/menu, the call fails with (from /temp/pndrun_kblayout.out):


/usr/pandora/scripts/pnd_run.sh: line 544: ./keymaps/German-external-qwertz: Permission denied


Even if I start the pnd_run.sh script using sudo, I get the Permission denied error.


Is this a design flaw in the PND system?


Or is there anything I need to consider when storing PNDs on the root fs?


The reason for storing the PND in the root fs is, that I want the configbutton Plugin to have a central place, existent on all Pandoras, to look for the PND.


An alternative might be to extract the relevant files from the PND and supply it with the sonfigbutton Plugin. However, of course this would only work with slaeshjag's permission, and it's a less elegant solution. Also, I'd like to understand what's going on here.


Thank you!


Daniel

 

[EvilDragon]

For security reasons, PNDs are always run with user permissions.


If any app inside a PND needs root access, you need to run it with gksu.


It will then ask for the users password.


So if you got an ext3-filesystem and the appdata-directory is not writable by the user, you will get permission erros.


Running pnd_run.sh with sudo won't help, as the PND itself will be run with user rights.

 

[hmc]

ah, thanks. So non-writable appdata is the key.


But how do I use gksu(do) here, without modifying the PND?

/usr/pandora/scripts/pnd_run.sh -p /pandora/menu/kblayout.pnd -e "[b]gksudo [/b]./keymaps/German-external-qwertz" -b "kblayout"

leads to

/usr/pandora/scripts/pnd_run.sh: line 546: [b]./gksudo[/b] ./keymaps/German-external-qwertz: No such file or directory

(same for "gksu").


And:


Does that mean, that every PND will fail, that is started from root fs, becasue every PND needs to write an appdata directory on first launch?


Daniel

 

[mcobit]

use gksu instead of ./gksu ?


Edit: Whats the tag for?





Edit2: Put the gksu command in front of the pnd_run command?

 

[hmc]

Hi mcobit,


1. I used gksu, not ./gksu. See my code in http://boards.openpandora.org/index.php?/topic/9688-differences-of-a-pnd-residing-on-fat-vs-ext-root-fs/#entry178865. It's just the pnd_run mechanism, which seems to translate that to ./gksu.


2. (your Edit) oops, the tag seems to be inserted by the board here, if you mark some contents inside a

[B] environment to be bold. I hoped that the text would actually be displayed bold.[/B]

3. (your Edit2): As per ED (and my tests confirm that) this does not solve the problem.

 

[laurencevde]

eehm, change the ownership of the appdata-directory on your root-partition, creating it if it doesn't exist yet?

 

[hmc]

Original permissions of /pandora/appdata:

drwxr-xr-x  8 root root 4096 Aug 21 13:03 appdata

then I did

pan1sd:~$ sudo chmod a+w /pandora/appdata

verified the change:

drwxrwxrwx  8 root root 4096 Aug 21 13:03 appdata

but still the same result when trying to execute the script within the PND.


Daniel

 

[laurencevde]

I guess the pnd's appdata-dir already exists? In that case, you'll need to change the permissions recursively. And you might want to change who owns /pandora/appdata.


sudo chown -R <user>:<group> /pandora/appdata should do the trick.


But it's also possible that the pnd attempts to execute "./keymaps/German-external-qwertz" while it isn't executable (which gives you a permission denied as well)... On FAT, all files normally get the executable-bit set.

 

[hmc]

yes, the direcotry /pandora/appdata/kblayout exists.


And it already has drwxrwxrwx permissions.


chowning /pandora/appdata to be owned by the main user is probably not such a good idea, because 1st it's not the firmware default (my stuff should run on default firmware, too!), and 2nd because then it would work only for one user, except if I begin to mess with groups...


Regarding ./keymaps/German-external-qwertz executability: I thought it wouldn't matter, on what file system the PND resides, as it is mounted as a squashfs and that's independent from the outside file system? Or am I wrong?


Daniel

 

[WizardStan]

Try manually mounting and running the script

/usr/pandora/scripts/pnd_run.sh -p [PATH_TO_PND]/kblayout.pnd -b "kblayout" -m

cd /mnt/utmp/kblayout

./keymaps/German-external-qwertz

 

[hmc]

Interesting!


Indeed, when I mount the PND from the FAT partition, the scripts have executable flags.


If mounted from the ext3 partition, they don't have these flags.


So it is a bug of the PND, because the PND author has not explicitly set the executable flags for the scripts?


Edit:


And why do the permissions of files INSIDE the PND depend on the OUTSIDE file system?


Thanks!


Daniel

 

[laurencevde]

PND's are run within a unionfs of the (ro) PND and the (rw) appdata-dir.


This PND's run-script copies the (non-executable) contents of the presets-dir to the keymaps-dir (which gets created in appdata/kblayout), asks for a keymap and then runs 'sh "keymaps/$keymap"', which doesn't require the file to be executable. I don't know what that copying is good for.


So you're simply using the PND in a way it's not designed for. You could change your command into "./setxkbmap -layout de", which is what German-external-qwertz does. Appending "sh" to your command will not work, as pnd_run.sh appends ./ to commands that don't start with ./

 

[WizardStan]

You can repack the PND with the right permissions or as a temporary work around copy the binary to the appdata directory and give it the right permissions there.