dflemstr
It's a ball.
For some reason, when I and some other people started talking about how the PND format currently is limited and not-so-limited and such things, people got very upset, started complaining, worrying and arguing over pointless things and imaginary issues with the PND system, polluting all of the discussion threads that were going on. I therefore will take some of my recent posts, merge them into this one, and let the discussion continue here. Fell free to continue flaming in the other threads if you so wish, but please stay out of this one.
The whoel discussion is about how the PND format could be extended to not only package music players or games, but also things such as icon themes or (for the really geeky people among us) web servers or desktop environments. Here's my proposed solution to that problem (taken from another post):
What I think would be nice is that you'd have 1 folder inside of the PND (say, "overlay/") that can contain symlinks to files elsewhere in the PND (and only symlinks, nothing else), so that when the PND gets mounted, the PND daemon takes all of the symlinks in the overlay folder, puts them directly on the NAND itself (the NAND writes are not so limited that we can't afford to write 20-byte files) and resolves the symlinks to point to the location where the PND is mounted.
If we don't want any NAND writes at all, an alternative solution would be to create one single UnionFS over the NAND that is combined with a RAM-disk, and create all of the symlinks on that RAM-disk.
Anyways, to show how this works, let's say that you have a PND like this:
...and it becomes this when mounted:
The PND daemon would of course keep track of which symlinks belong to which PND, and remove them when the PND is unmounted. If the system is shut down while PNDs are still mounted, this shouldn't be a problem, since unresolvable symlinks will look the same to applications as missing files, and if an UnionFS with a RAM disk is used for the symlinks, they will of course disappear when the system is shut down.
Discussion arose about wether the PND should be allowed to "override" or "overwrite" files on the NAND, and to that I said:
I don't think that it necessarily is a good idea to allow the "overriding" of files at all. Dependency injection would be a possible exploit if it was allowed, for example (Imagine rewriting libmagic.so and "injecting" (replacing) the original version so that all files are opened by a specific program, for example, or that someone would rewrite libglib.so, thus compromising the whole userspace).
I believe in a more strict rule, that PNDs aren't allowed to "replace" any file in the system, ever, because of the security issues.
Also, since the ld systems (that ake care of dynamic libraries) in all Linux distributions already have versioning built into them (check your own /usr/lib folder!), that would also allow for something like God Ginrai probably was thinking about; imagine that the file structure on the NAND looks like this (This tree was taken directly from my Arch install, btw):
...and a PND for some reason requires a newer version of libxml2.so (let's say, 2.7.5). It would then, when mounted, create a symlink like this:
...and applications inside of the PND would of course dynamically link to /usr/lib/libxml2.so.2.7.5, because that's the version they're using.
If and when the "official" NAND firmware then gets the libxml2 version 2.7.5 included, the above will silently transform into this, because PNDs may not override actual NAND files:
...and all will be well, plus the PND will benefit from any official optimizations that were done in the official version of libxml2. When version 2.7.5 then becomes out of date, or libxml3 is released, the symlink to the PND version will activate again, and will thus still work, despite the fact that the wrong version of libxml is on the NAND.
I am really starting to believe that this could actually work. I'd like to hear WizardStan's comments on it, though, as he seems to have opinions about it still
Let your opinions be heard!
The whoel discussion is about how the PND format could be extended to not only package music players or games, but also things such as icon themes or (for the really geeky people among us) web servers or desktop environments. Here's my proposed solution to that problem (taken from another post):
What I think would be nice is that you'd have 1 folder inside of the PND (say, "overlay/") that can contain symlinks to files elsewhere in the PND (and only symlinks, nothing else), so that when the PND gets mounted, the PND daemon takes all of the symlinks in the overlay folder, puts them directly on the NAND itself (the NAND writes are not so limited that we can't afford to write 20-byte files) and resolves the symlinks to point to the location where the PND is mounted.
If we don't want any NAND writes at all, an alternative solution would be to create one single UnionFS over the NAND that is combined with a RAM-disk, and create all of the symlinks on that RAM-disk.
Anyways, to show how this works, let's say that you have a PND like this:
Code:
foo.pnd/
|-- libfoo.so
|-- myfile.png
`-- overlay/
`-- usr
`-- lib
`-- libfoo.so -> /libfoo.so #In the PND, the "/" dir means the root dir of the PND since it's isofs
Code:
/
|-- mnt/
| `-- pnd019283/
| |-- myfile.png
| `-- libfoo.so
`-- usr
`-- lib
`-- libfoo.so -> /mnt/pnd019283/libfoo.so
The PND daemon would of course keep track of which symlinks belong to which PND, and remove them when the PND is unmounted. If the system is shut down while PNDs are still mounted, this shouldn't be a problem, since unresolvable symlinks will look the same to applications as missing files, and if an UnionFS with a RAM disk is used for the symlinks, they will of course disappear when the system is shut down.
Discussion arose about wether the PND should be allowed to "override" or "overwrite" files on the NAND, and to that I said:
I don't think that it necessarily is a good idea to allow the "overriding" of files at all. Dependency injection would be a possible exploit if it was allowed, for example (Imagine rewriting libmagic.so and "injecting" (replacing) the original version so that all files are opened by a specific program, for example, or that someone would rewrite libglib.so, thus compromising the whole userspace).
I believe in a more strict rule, that PNDs aren't allowed to "replace" any file in the system, ever, because of the security issues.
Also, since the ld systems (that ake care of dynamic libraries) in all Linux distributions already have versioning built into them (check your own /usr/lib folder!), that would also allow for something like God Ginrai probably was thinking about; imagine that the file structure on the NAND looks like this (This tree was taken directly from my Arch install, btw):
Code:
/usr/lib/
|-- libxml2.so -> libxml2.so.2.7.3 (symlink)
|-- libxml2.so.2 -> libxml2.so.2.7.3 (symlink)
`-- libxml2.so.2.7.3
Code:
/usr/lib/
|-- libxml2.so -> libxml2.so.2.7.3 (symlink)
|-- libxml2.so.2 -> libxml2.so.2.7.3 (symlink)
|-- libxml2.so.2.7.5 -> /mnt/pnd7273232/libxml2.so (symlink) <--
`-- libxml2.so.2.7.3
If and when the "official" NAND firmware then gets the libxml2 version 2.7.5 included, the above will silently transform into this, because PNDs may not override actual NAND files:
Code:
/usr/lib/
|-- libxml2.so -> libxml2.so.2.7.5 (symlink)
|-- libxml2.so.2 -> libxml2.so.2.7.5 (symlink)
`-- libxml2.so.2.7.5
Code:
/usr/lib/
|-- libxml3.so -> libxml3.so.3.0.0 (symlink)
|-- libxml3.so.3 -> libxml3.so.3.0.0 (symlink)
|-- libxml2.so.2.7.5 -> /mnt/pnd7273232/libxml2.so (symlink) <--
`-- libxml3.so.3.0.0
I am really starting to believe that this could actually work. I'd like to hear WizardStan's comments on it, though, as he seems to have opinions about it still
Let your opinions be heard!