Discussion About Additions To The Pnd Format

[dflemstr]

The system as it is planned to be at the moment cannot compromise the system, with or even without the need for root passwords and user authentication. As said above, the whole merged environment can be put anywhere, it's very easy to constrain the pnddaemon so that it's only allowed to overlay certain directories (you could even enforce this on a kernel level), and no PNDs are able to provide daemons that will be launched at boot.

There were three use cases you provided beyond the original "click to run" that you wanted for the PND format.
1) Start daemons like Apache automatically
2) Install icon themes
3) Extra libraries and codecs
By your design, (1) is completely out. It's a use case that can never be achieved.
I was actually expecting a different response to the /etc/rc problem, and was preparing an argument that would render (2) useless as well, but simply rejecting overlays to /etc/rc solves that problem, even if it does eliminate one of the other use cases.
Except that right now it's /etc/rc. What happens if someone else thinks up a way of abusing a different directory? Block that one as well?
For some reason, inclusive feels better than exclusive: "you can overlay into these directories, adding more overtime as needed" sounds safer than "you cannot write into these directories, adding more as flaws are found".

OK; read the posts I made while you were posting (or deliberately skipped, but I don't think that ).

So, you say that it would be good if we'd be inclusive and not exclusive...

Imagine the follwing scenario, then:
1. First, create a setup like this (this is before the UnionFS comes into play):

/ - The real root directory of the system
  dev
    shm
      overlays - Where all the PND symlinks are copied into (a ramdisk)
        usr
          lib
            lib.so.2 -> /mnt/pnd01/lib.so
  mnt
    pnd01 - A mounted PND
      lib.so
      overlay
        usr
          lib
            lib.so.2 -> /lib.so
  usr
  etc
  var
  pnd
    root - What will become the overlay version of the system
    original - The directory with exposed directories
      usr => /usr - This is a HARDLINK, not a symlink, as shown by the => arrow.
      lib => /lib
      home => /home
      etc - We want to only allow parts of etc to be "changed" by PNDs
        gtk-2.0 => /etc/gtk-2.0
        ...and so on...

The /pnd/original directory contains all of the folders and files that we want PNDs to have *access* to. If a folder or file isn't linked to in the "original" folder, it won't be seen by PNDs. They wonät be able to read inaccessible folders, nor be able to write to them or add symlinks to them. "original" is the control folder with all of the folders that are allowed.

Now, with "mount -t unionfs -o dirs=/dev/shm/overlays:/pnd/original none /pnd/root", the contents of /pnd/original and /dev/shm/overlays will be merged, and the result shown in /pnd/root. It would thus look like this:

/
  ...same as above, completely unchanged...
  pnd
    root
      usr
        ...all the contents of /usr
        lib
          ...all the contents of /usr/lib
          lib.so.2 -> /mnt/pnd01/lib.so
      lib
        ...all the contents of /lib
      home
        ...all the contents of /home
      etc
        gtk-2.0
          ...all the contents of /etc/gtk-2.0

...and that would be it. Perfectly safe, and perfectly stable if you chroot PNDs into /pnd/root. You get almost the same power as you get with AppArmor, just by using symlinks, hardlinks, and UnionFS.

 

[verm71]

About the home directory. If you use the nand as home, people will use it as one. Most programs will automatically suggest saving everything there, so people will.

How difficult would it be to clean up and go back to 100% factory content, with no trash files for old applications no longer in use?

If you put home to an sd card, you lose settings as most programs save them there.

But those "lost" settings went with the programs that are also on the SD card. If the application disappears then so do its settings. I despise seeing years of .files in my home directory for applications I forgot I had deleted.

I'm thinking of the mantra, "No SD card, no settings". That would apply for the NAND-supplied apps as well. Only OS-critical stuff like passwords belong in there. You want to customize the behavior of an app, you'll need an SD card to save those settings. There are two slots. So it's not like you can't dedicate one slot to always have the same "Home" SD card in it, no? In a way, you could have different users have their own different "Home" SD card, but I think that would be pushing it. This is what directories were invented for.

Best way I see would be to keep the home on NAND, but make clearly labeled "SD1" and "SD2" symlinks to the cards' respective mount points to make it absolutely clear that you are not saving on SD's when in home dir.

Interesting, but I also need a way to lend my Pandora to a neophyte and know they can't touch the NAND in any way.

Seems like something that will need some per-user configurable setting. (e.g. "Where do you want your HOME to be? 1. NAND (*warning blah blah), 2. SD1, 3. SD2, 4. purely RAM)") Just a thought.

 

[dflemstr]

@ the 8 answers that popped up while I was typing <_< :

1. I'm as I said not talking about UnionFSing any SD cards or /home directories here. That's a discussion for another time. PLEASE don't discuss anything related to /home any longer! That's not the issue here!
2. UnionFS doens't care about which FS'es you use or don't use, since it mounts two or more FOLDERS and not two FILESYSTEMS or PARTITIONS. Read my above answer for the command details + the answer on page 3 and try it out yourself!
3. I've always been talking about using a RAMdisk for the (readonly, symlink-only) overlays that PNDs will provide. For those uninitiated to the Ways of Linux, know that any directory I create in /dev/shm (The SHared Memory DEVice) automatically is created in RAM, and not on any disk. Read my previous posts to further understand how the system would work.

Oh and please, If you don't understand the commands that I've used in my recent example on page 3 and on this page, and can't/won't find out, I beg you to not participate in this discussion any longer. You will probably then mention issues that have already been solved by using thos ecommands, or bring up complaints that aren't valid. Please try to read up on this stuff before saying "But I don't want my SD card to be touched" or "The NAND is holy, don't do stuff with it!". I have never spoken about SD cards, the /home directory or any writes to the NAND in my recent posts, and those three things are actually irrelevant to the discussion at hand.

 

[Pickle]

If this just about getting the system to find extra libs on the SD card why cant LD_LIBRARY_PATH have the SD path or the PWD path?

 

[dflemstr]

(sorry for double posts but I can't keep up with the stream of posts otherwise)

About the home directory. If you use the nand as home, people will use it as one. Most programs will automatically suggest saving everything there, so people will.

How difficult would it be to clean up and go back to 100% factory content, with no trash files for old applications no longer in use?

If you put home to an sd card, you lose settings as most programs save them there.

But those "lost" settings went with the programs that are also on the SD card. If the application disappears then so do its settings. I despise seeing years of .files in my home directory for applications I forgot I had deleted.

I'm thinking of the mantra, "No SD card, no settings". That would apply for the NAND-supplied apps as well. Only OS-critical stuff like passwords belong in there. You want to customize the behavior of an app, you'll need an SD card to save those settings. There are two slots. So it's not like you can't dedicate one slot to always have the same "Home" SD card in it, no? In a way, you could have different users have their own different "Home" SD card, but I think that would be pushing it. This is what directories were invented for.

Best way I see would be to keep the home on NAND, but make clearly labeled "SD1" and "SD2" symlinks to the cards' respective mount points to make it absolutely clear that you are not saving on SD's when in home dir.

Interesting, but I also need a way to lend my Pandora to a neophyte and know they can't touch the NAND in any way.

Seems like something that will need some per-user configurable setting. (e.g. "Where do you want your HOME to be? 1. NAND (*warning blah blah), 2. SD1, 3. SD2, 4. purely RAM)") Just a thought.

I'll say this for the third time: Your system will never be changed; nothing will be written to your disks and nothing will be changed. If you reboot your system, it will have the "factory defaults" as you put it; there's no cleaning up to do. Everything that I have mentioned so far is happening in RAM and it will stay that way. Also (and I say this for the fourth time): I have NEVER talked about the /home directory and it's location! That discussion is off-topic! I have also never talked about SD cards! They have only been mentioned by others as suggestions that then were replaced by other suggestions that are RAM-based! Please refrain from discussiong /home or sd-cards in this thread!

 

[dflemstr]

If this just about getting the system to find extra libs on the SD card why cant LD_LIBRARY_PATH have the SD path or the PWD path?

Because the discussion isn't primarily about libraries. What if a PND wants to provide files in /usr/share/icons? There's no path for that, so how would you solve that? That's why I've started this discussion in the first place.

 

[Pickle]

If this just about getting the system to find extra libs on the SD card why cant LD_LIBRARY_PATH have the SD path or the PWD path?

Because the discussion isn't primarily about libraries. What if a PND wants to provide files in /usr/share/icons? There's no path for that, so how would you solve that? That's why I've started this discussion in the first place.

OK I think I agree with this solution for read only data files. I think it gets hairy when we start talking about writing, which I think your trying to avoid talking about.

So if each pnd file can have its own overlay, are all overlays going to be loaded at once. Or is an overlay going to be loaded only when a pnd is has been selected to be run?

 

[God Ginrai]

If this just about getting the system to find extra libs on the SD card why cant LD_LIBRARY_PATH have the SD path or the PWD path?

Because the discussion isn't primarily about libraries. What if a PND wants to provide files in /usr/share/icons? There's no path for that, so how would you solve that? That's why I've started this discussion in the first place.

OK I think I agree with this solution for read only data files. I think it gets hairy when we start talking about writing, which I think your trying to avoid talking about.

So if each pnd file can have its own overlay, are all overlays going to be loaded at once. Or is an overlay going to be loaded only when a pnd is has been selected to be run?

The overlay will be loaded when the PND is mounted, I believe.

-God Ginrai

 

[Pickle]

The overlay will be loaded when the PND is mounted, I believe.

Yeah that would be the logic approach.

Okay heres another problem, back to the quake example, we cant distribute the pak's, but in the method you want to use the files would have to be in the pnd file. Basically how does this solution account for the pnd with external data?
Can there be a master overlay in folder format not in a pnd file?

 

[God Ginrai]

The overlay will be loaded when the PND is mounted, I believe.

Yeah that would be the logic approach.

Okay heres another problem, back to the quake example, we cant distribute the pak's, but in the method you want to use the files would have to be in the pnd file. Basically how does this solution account for the pnd with external data?
Can there be a master overlay in folder format not in a pnd file?

I might not be understanding your question right, but I'm pretty sure that all the PNDs share the same overlay.

-God Ginrai

 

[dflemstr]

The overlay will be loaded when the PND is mounted, I believe.

Yeah that would be the logic approach.

Okay heres another problem, back to the quake example, we cant distribute the pak's, but in the method you want to use the files would have to be in the pnd file. Basically how does this solution account for the pnd with external data?
Can there be a master overlay in folder format not in a pnd file?

What exactly do you mean? Why couldn't you simply put the level files in a PND file? Oh and remember that you could easily have two PNDs, one with the quake 3 executables and one with the level files, since all PNDs share the same root overlay.

E.g.:

/
  media
    sd1
      pnd-with-quake-exes.pnd - here are the unmounted PND files btw
      pnd-with-quake-levels.pnd
  mnt
    pnd-with-quake-exes
      ioquake-start.sh
      overlay
        usr
          bin
            ioquake -> /ioquake-start.sh
    pnd-with-quake-levels
      levelfile1
      levelfile2
      overlay
        usr
          share
            ioquake - Or some such location
              level1 -> /levelfile1
              level2 -> /levelfile2
  dev
    shm
      overlays - All the overlays are merged in this folder first
        usr
          bin
            ioquake -> /mnt/pnd-with-quake-exes/ioquake-start.sh
          share
            level1 -> /mnt/pnd-with-quake-levels/levelfile1
            level2 -> /mnt/pnd-with-quake-levels/levelfile2
...etc...

 

[Pickle]

The overlay will be loaded when the PND is mounted, I believe.

Yeah that would be the logic approach.

Okay heres another problem, back to the quake example, we cant distribute the pak's, but in the method you want to use the files would have to be in the pnd file. Basically how does this solution account for the pnd with external data?
Can there be a master overlay in folder format not in a pnd file?

What exactly do you mean? Why couldn't you simply put the level files in a PND file? Oh and remember that you could easily have two PNDs, one with the quake 3 executables and one with the level files, since all PNDs share the same root overlay.

Your fine with requiring everyone to have to package all game data up they own into PND's? We can not distribute copyright material, such as any pak's/wad's that ID made for doom/quake.
I would rather have a folder (not in a pnd) on the sd card where everyone can just drop in the data.

 

[Caine]

I'm not entirely sure I still understand the use of the symlinks here. I thought you initially used them to prevent writing large amounts of data to the NAND or in this case RAM.

Are they required instead to create a single union which is shared by all PNDs? If I read the documentation of UnionFS correctly, we can just add volumes to the mountpoint:

# mount -t unionfs -o remount,add=/foo none MOUNTPOINT

So why do we not join the filesystem directly? Example:

/ - The real root directory of the system
  dev
  mnt
    pnd01 - A mounted PND
      overlay
        usr
          lib
            lib.so.2
  usr
  etc
  var
  pnd
    root - What will become the overlay version of the system
    original - The directory with exposed directories
      usr => /usr - This is a HARDLINK, not a symlink, as shown by the => arrow.
      lib => /lib
      home => /home
      etc - We want to only allow parts of etc to be "changed" by PNDs
        gtk-2.0 => /etc/gtk-2.0
        ...and so on...

Join them:
# mount -t unionfs -o dirs=/mnt/pnd01/overlay:/pnd/original none /pnd/root

/
  ...same as above, completely unchanged...
  pnd
    root
      usr
        ...all the contents of /usr
        lib
          ...all the contents of /usr/lib
          lib.so.2
      lib
        ...all the contents of /lib
      home
        ...all the contents of /home
      etc
        gtk-2.0
          ...all the contents of /etc/gtk-2.0

Adding another pnd:
# mount -t unionfs -o remount,add=/mnt/pnd02/overlay none /pnd/root
Removing a pnd:
# mount -t unionfs -o remount,del=/mnt/pnd01/overlay none /pnd/root

Haven't tested any of this yet though.

 

[dflemstr]

I'm not entirely sure I still understand the use of the symlinks here. I thought you initially used them to prevent writing large amounts of data to the NAND or in this case RAM.

Are they required instead to create a single union which is shared by all PNDs? If I read the documentation of UnionFS correctly, we can just add volumes to the mountpoint:

# mount -t unionfs -o remount,add=/foo none MOUNTPOINT
...

Haven't tested any of this yet though.

You, sir, are a genious. Either that, or you've simply read the manpages more than I have. Gentlemen, we just cut away one whole layer of complexity from the system. We now don't even have to care about the overwriting of symlinks; UnionFS will handle it for us.

I at first thought that you couldn't add overlays to unionfs after it had been mounted, but I of course now see that this must be possible. The question remains, however, if it's possible to add overlays to the *bottom* of the union stack? Because that's the only way to get the behavior we need.

 

[God Ginrai]

The overlay will be loaded when the PND is mounted, I believe.

Yeah that would be the logic approach.

Okay heres another problem, back to the quake example, we cant distribute the pak's, but in the method you want to use the files would have to be in the pnd file. Basically how does this solution account for the pnd with external data?
Can there be a master overlay in folder format not in a pnd file?

What exactly do you mean? Why couldn't you simply put the level files in a PND file? Oh and remember that you could easily have two PNDs, one with the quake 3 executables and one with the level files, since all PNDs share the same root overlay.

Your fine with requiring everyone to have to package all game data up they own into PND's? We can not distribute copyright material, such as any pak's/wad's that ID made for doom/quake.
I would rather have a folder (not in a pnd) on the sd card where everyone can just drop in the data.

I see what you mean. But users can make their own PNDs, so they could make one that includes their own PAK files that they have obtained through whatever means.

-God Ginrai

 

[polyroy]

Haven't tested any of this yet though.

Minor: you can't hardlink directories. You can, however, mount --bind them, which accomplishes the same.

I at first thought that you couldn't add overlays to unionfs after it had been mounted, but I of course now see that this must be possible. The question remains, however, if it's possible to add overlays to the *bottom* of the union stack? Because that's the only way to get the behavior we need.

So there appears to be no problem after all? I'm pretty certain that at least aufs can do this (supposedly the improved version of unionfs which does a lot of branch management).

The only issue remaining is testing what happens when branches disappear when layered into some odd filesystems. Is this stable, can the kernel cope properly in complex setups?

 

[dflemstr]

The only issue remaining is testing what happens when branches disappear when layered into some odd filesystems. Is this stable, can the kernel cope properly in complex setups?

Why not?
BTW, Remember that we actually don't deal with filesystems here; we just merge folders, so I don't understand "some odd filesystems".

So, if we remove a directory from the union, its files will disappear, or alternatively, if there are multiple PNDs providing the same file, another overlay will provide the file instead. It'll look like the file was deleted to any applications depending on the file, and they should be able to handle such situations (and an user shouldn't unmount a PND while he's using contents of it anyways)

 

[Caine]

So there appears to be no problem after all? I'm pretty certain that at least aufs can do this (supposedly the improved version of unionfs which does a lot of branch management).

Yes this does come from the documentation of aufs. Just ran a simple test on an Ubuntu machine which apparently doesn't use aufs (i.e. it doesn't work).

So, if we remove a directory from the union, its files will disappear, or alternatively, if there are multiple PNDs providing the same file, another overlay will provide the file instead. It'll look like the file was deleted to any applications depending on the file, and they should be able to handle such situations (and an user shouldn't unmount a PND while he's using contents of it anyways)

Assuming a user knows he's using the file. If two PNDs are using the file, the one not being shut down might have a lock on the actual file being removed from the union. I strongly doubt UnionFS will automatically revert to the file to a lower layer.

del:dir
...
If a process is referencing the file/directory on the deleting branch (by open, mmap, current working directory, etc.), aufs will return an error EBUSY.

 

[polyroy]

The only issue remaining is testing what happens when branches disappear when layered into some odd filesystems. Is this stable, can the kernel cope properly in complex setups?

Why not?
BTW, Remember that we actually don't deal with filesystems here; we just merge folders, so I don't understand "some odd filesystems".

So, if we remove a directory from the union, its files will disappear, or alternatively, if there are multiple PNDs providing the same file, another overlay will provide the file instead. It'll look like the file was deleted to any applications depending on the file, and they should be able to handle such situations (and an user shouldn't unmount a PND while he's using contents of it anyways)

Well, I don't understand the details, but the least complex setup is going to be something like this:

/dev/sdb, SD card device
/mnt/sdb1, with EXT3 (for the journalling!)
---> PND file loopback mounted on /dev/loopx
/dev/loopx, losetup device PND
/mnt/pndx, where the prior loop is mounted
---> overlay directory which is unionfs'd/aufs'd with /pnd/overlay

If we pull the SD card, there is no time at all for filesystem cleanups (not a problem for read-only devices). Also, quite suddenly, quite a lot of filesystems lose their originating devices. A kernel panic is probably out of the question, but what about time-outs and the like? Will forced, unexpected removal be quick and painless? For every PND you'll have a device, a mount points and an overlay branch active. For hundreds of simultaneously active PND's this might mean trouble.

Just looking for some confirmation

 

[dflemstr]

Assuming a user knows he's using the file. If two PNDs are using the file, the one not being shut down might have a lock on the actual file being removed from the union. I strongly doubt UnionFS will automatically revert to the file to a lower layer.

del:dir
...
If a process is referencing the file/directory on the deleting branch (by open, mmap, current working directory, etc.), aufs will return an error EBUSY.

There's always lazy unmounting
And if the file "forcefully" disappears (because the PND providing it physically disappears after it's unmounted because an Sd card is removed or something), aufs really should provide the file from a lower layer; it's a bug otherwise.