Pre Installed Programs
- Thread starter Rygiz
- Start date
Bosbeetle
Terminally lost
Sounds n00b friendly, thanks 
Last edited by a moderator:
OrR
Corporate games suck.
Even though my understanding is somewhat limited, I just love all this crazy Linux stuff. Sounds like you have thought it through thoroughly and found some great solutions. I guess that's the positive side of the hardware delay.
Edit: You've probably already thought about this but you need to make sure that there is a way to rescan the SD card either automatically or manually even if it's not taken out and reinserted because in many cases the .pnd files will probably be downloaded directly from the browser on the handheld.
Sounds like you have thought it through thoroughly and found some great solutions. I guess that's the positive side of the hardware delay. Edit: You've probably already thought about this but you need to make sure that there is a way to rescan the SD card either automatically or manually even if it's not taken out and reinserted because in many cases the .pnd files will probably be downloaded directly from the browser on the handheld.
Last edited by a moderator:
Vimacs
Don't be evil!
Absolutely! libpnd is always scanning for changes using inotify, it doesn't matter where they come from.'OrR' said:
A removed sd card is actually pretty much the same to libpnd as rm -rf /mnt/sdX/ .
Remember that its all wip thou.
Last edited by a moderator:
cb88
The mighty inverse laplacinator
heh... no matter what you guys come up with its bound to be pretty decent you seem to have tought out a pretty fair/balanced idea even if not optimal in some areas
also make an SD card ejector!!! pfft even windows users know you have to eject USB drives
you seem to have tought out a pretty fair/balanced idea even if not optimal in some areasalso make an SD card ejector!!! pfft even windows users know you have to eject USB drives
_VWV_
Member
What about security, access permissions and so on? What if I download a firefox.pnd file with a rootkit in it?
cb88
The mighty inverse laplacinator
they don't make many root kits for linux
only download from the official tested repositories and you should be fine ... unless you are talking something more robust like package authentication
only download from the official tested repositories and you should be fine ... unless you are talking something more robust like package authentication
Last edited by a moderator:
skeezix
Internal Development
libpnd and related so far is not a big fancy crazy thing; not enough time for that, and don't want to overextend to introduce a lot of issues.. can grow it over time. That said, I am trying to show restraint in writing things so that is all fairly obvious in function and laid out pretty easily.. so that _people can extend it_. The source is all open, people can make patches and see about getting them in.'Dutch_Cap' said:
ie: I'm trying to get trhe design 'half right', and the internals 'good enough to work'. Some of it is a cheap hack internally, but the design should stand up. The cheap stuff can get taken out and fixed up over time, without breaking the desing or interface, ideally. Even if the interface has to change, such is life.. but I/we do the best we can in the time we have
That said, libpnd is not purely my work; others have had the finger in. It would be unjust for me to take all the credit (or blame
And libpnd is a small piece of the system as a whole.
jeff
Security wise .. like anything else, you have to sort of trust that the repository is vetted/solid. Someone poisons the redhat/freebsd/debian/etc repo with a bad package, bad things happen.
As to what user things will all be running as and so on, I'm not sure where thet lays. I doubt people wil be using root in the device by default; certainly we've got/had images where the first thing that happens is you create your user (using a one screen gui) and go from there, but I don't know whetre its at or what we'll be rolling with.
(I should stop talking, I over speak
Chip, come get me with the duct-tape!)jeff
Last edited by a moderator:
Excellent!'Vimacs' said:
If the hardware can't prevent an arbitrary removal of the SD card, the software ought to cope with the arbitrary removal of the SD card. (This is why Mac's didn't/don't have eject buttons for floppies or optical discs.) "Even windows users know..." except that many of my personal acquaintances know no such thing. If a system auto-mounts (as, for example, Ubuntu (Nautilus?) does much to my delight) then it ought to auto-unmount on disc removal. It seems like all that would be required is to write in atomic transactions just like any reasonable DB software. Always leaving the disc in a stable (or recoverable) state. I wonder whether some of the current fs's in the Linux ecosystem would be well-suited to such a use?
I might be going a little off-topic.
But I wanted to say this plan (as outlined by Jeff) sounds great and I'm particularly impressed that you guys are planning to cope with arbitrary SD card removal. It makes tons of sense.--Todd
Last edited by a moderator:
'todd' said:Excellent!'Vimacs' said:
If the hardware can't prevent an arbitrary removal of the SD card, the software ought to cope with the arbitrary removal of the SD card. (This is why Mac's didn't/don't have eject buttons for floppies or optical discs.) "Even windows users know..." except that many of my personal acquaintances know no such thing. If a system auto-mounts (as, for example, Ubuntu (Nautilus?) does much to my delight) then it ought to auto-unmount on disc removal. It seems like all that would be required is to write in atomic transactions just like any reasonable DB software. Always leaving the disc in a stable (or recoverable) state. I wonder whether some of the current fs's in the Linux ecosystem would be well-suited to such a use?
I might be going a little off-topic.
--Todd
You'd have to fsync after every change, which will kill performance. Maybe fsync after X seconds or something like that. Not guaranteed to not corrupt it (not possible to anyway), but reasonably safe.
Last edited by a moderator:
BackAssward
Active Member
- Joined
- Apr 3, 2008
- Messages
- 985
Are you on drugs? The term "Root Kit" comes from *nix. E.g., root level access... a term that means nothing in Windows (admin level is what it is called there).'cb88' said:they don't make many root kits for linux
only download from the official tested repositories and you should be fine ... unless you are talking something more robust like package authentication
See:
en.wikipedia.org/wiki/Rootkit#History
... Were you possibly thinking "Virus" or "Trojan" when you replied?
Last edited by a moderator:
AireTamStorm
Unix Addict
'skeezix' said:...
After advocating Unioned Filesystems to the death, basically beyond what is necessary and/or helpful to the community (http://www.gp32x.de/board/index.php?showtopic=46738])
How will you assure synchronization between NAND and Union installed packages?
Last edited by a moderator:
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
'AireTamStorm' said:
Last edited by a moderator:
I've been thinking of a similar app installation system for linux (also inspired by os x's .app).
I was also thinking of including all dependencies as packages (opkg/deb/rpm/whatever) in the .app (or .pnd in this case) file and install them when the file is discovered, if there are no newer versions already installed.
The main problem is that it would be good to have this installation of packages optional if conflicts are considered likely (multiple versions of the same thing, hard to modify nand, etc). So the .pnd could provide the dynamic libraries and recipes and tools to create packages for them. It could be too slow to create and install packages at the first run, but since .ipkg (or .opkg) are simpler and there is no need for complicated metadata, it should be fast enough.
The main advantage for installing packages is that other apps with the same dependencies would use the same library and share it if run at the same time, saving ram. The libraries could also be optionally deleted from the .pnd after installation to save space, but modifying the .iso or SquashFS image could be problematic. This whole thing might be too complex for it's own good.
I was also thinking of including all dependencies as packages (opkg/deb/rpm/whatever) in the .app (or .pnd in this case) file and install them when the file is discovered, if there are no newer versions already installed.
The main problem is that it would be good to have this installation of packages optional if conflicts are considered likely (multiple versions of the same thing, hard to modify nand, etc). So the .pnd could provide the dynamic libraries and recipes and tools to create packages for them. It could be too slow to create and install packages at the first run, but since .ipkg (or .opkg) are simpler and there is no need for complicated metadata, it should be fast enough.
The main advantage for installing packages is that other apps with the same dependencies would use the same library and share it if run at the same time, saving ram. The libraries could also be optionally deleted from the .pnd after installation to save space, but modifying the .iso or SquashFS image could be problematic. This whole thing might be too complex for it's own good.
Last edited by a moderator:
sterling976
Member
- Joined
- Oct 7, 2008
- Messages
- 217
'WizardStan' said:I'm not 100% clear on all the details, and haven't done the reading (I know, shame on me), but I think the gist of it is:'AireTamStorm' said:
*** Assume the NAND side of the unioned mount is read-only, but the SD Card is read-write ***
1-Install a package and dependent libraries on a unioned filesystem shared across the NAND and SD card 1. (The files are written to the SD Card)
2-Remove SD card 1 and replace with SD card 2.
3-Install a package and dependent libraries on a unioned filesystem shared across the NAND and SD card 2.
4-For the sake of argument, let's assume that the second SD slot is taken up by another card, or that this process is repeated for a third SD card.
*** At this point, SD card 1 is no longer in the Pandora ***
5-Upgrade the system (including the libraries installed in steps 1 and 3, above -- oops, SD Card 1 isn't mounted, so those libraries aren't there!)
6-Remove SD card 2 and re-insert SD card 1.
7-Chaos ensues.
I can see this being a fairly significant problem, but again, I haven't done the research to see if there's an obvious solution.
Personally, I'm planning on getting around this by never removing one of the SD cards, and using an old-fashioned mount for most of the userspace directories (/home, /usr/lib, etc.. -- no, not /etc, just etc....). That way I don't have to worry about parity with the NAND -- it's all treated essentially as one filesystem (better hope I made backups
That said, I'm very impressed with the work that's being done in this area and don't want to discourage anyone from giving it a try -- if all the bugs get ironed out, it'll be SWEET!
Last edited by a moderator:
'skeezix' said:libpnd and related so far is not a big fancy crazy thing; not enough time for that, and don't want to overextend to introduce a lot of issues.. can grow it over time. That said, I am trying to show restraint in writing things so that is all fairly obvious in function and laid out pretty easily.. so that _people can extend it_. The source is all open, people can make patches and see about getting them in.'Dutch_Cap' said:
ie: I'm trying to get trhe design 'half right', and the internals 'good enough to work'. Some of it is a cheap hack internally, but the design should stand up. The cheap stuff can get taken out and fixed up over time, without breaking the desing or interface, ideally. Even if the interface has to change, such is life.. but I/we do the best we can in the time we have
That said, libpnd is not purely my work; others have had the finger in. It would be unjust for me to take all the credit (or blame
And libpnd is a small piece of the system as a whole.
So are you saying the behaviour is hardcoded into the daemon? The way I would do it, if the daemon discovers a PXML file it runs a shell script, with the path to the PXML as an argument. This way the user could change the behaviour relatively easily, just edit the shell script. I kind of assumed you were doing something like that.
Last edited by a moderator:
skeezix
Internal Development
Sterling.. do the reading, that case isn't going to happen.
ie: The NAND firmware, when written to will in theory writechanges to the user homedir also in NAND. (opkg, etc.)
pnd files will be on SD card, with union redirecting writebacks to the SD card in a well defined hierarchy.
Unpacked pnd files will be on the SD card, with writebacks gong directly into the directory (no voodoo.)
We're not having people using package managers that writeto NAND and also SD, because that leeds to insanity.
jeff
ie: The NAND firmware, when written to will in theory writechanges to the user homedir also in NAND. (opkg, etc.)
pnd files will be on SD card, with union redirecting writebacks to the SD card in a well defined hierarchy.
Unpacked pnd files will be on the SD card, with writebacks gong directly into the directory (no voodoo.)
We're not having people using package managers that writeto NAND and also SD, because that leeds to insanity.
jeff
Last edited by a moderator:
_VWV_
Member
My security concern was: I'm give an SD card with "some interesting stuff" and when I insert it into Panda the daemon finds "malware.pnd" or rootkit.pnd and happily installs the app without giving me any hint on what's happening. This is a security hole I think. You see, it has nothing to do with "trusted repos". I don't want to say I completely dislike the idea. I just think that the daemon should have minimal privileges and should be hardened against possible privilege escalation. I don't want this windoze shit that works through autorun.ini to be possible on panda.
Last edited by a moderator:
lulzfish
Pandora Defense Squad
That's not a vulnerability, it's a known feature of icon-based desktop environments like KDE and GNOME and maybe xfce!
You should be proud to have such a feature!
I guess you could add some sort of chroot jail. That might actually work pretty well, you would just have to keep all your saved games and whatnot on the SD card unless you backed them up manually.
That might only be a problem if the program asks for some system library that's outside of the chroot.
I'm not really an expert with Linux, but I think something like this might work.
chroot additive:
According to the Wikipedia, there are a few issues with the chroot thing I mentioned:
1. It requires root privileges [Like UAC, might be annoying for some users]
2. A root-privileged program can escape from chroot [Really an issue of user gullibility, as some security problems are]
3. Requires you to copy or symlink in needed system libraries and device files. This is a little inconvenient, but it's not horrible to ask programs to bring their own config files, savegames, and libraries to the place.
4. It's not actually meant to be used as a security measure. It's more of a testing and virtualization layer.
So, overall, it's easy to do and it's probably better than nothing, but it leaves a lot of room for improvement.
And as always, a socially engineered user can just say, "I don't have time for chroots, I'm trying to watch free porn here!" and bypass all the security. Not really a way around this.
You might also try something like:
1. Create a separate user "sandbox"
2. Give sandbox full permissions to his SD card, but no permissions to /home, and read-only or read-execute-only permissions for graphics libraries or whatever is expected to be on the system.
3. Use a su command to run untrusted programs as the sand box user.
4. If possible, maybe log suspicious calls and alert the user.
Again, I don't know a whole lot about Linux, but I think this could work as a basic defense against malware.
You should be proud to have such a feature!
I guess you could add some sort of chroot jail. That might actually work pretty well, you would just have to keep all your saved games and whatnot on the SD card unless you backed them up manually.
That might only be a problem if the program asks for some system library that's outside of the chroot.
I'm not really an expert with Linux, but I think something like this might work.
chroot additive:
According to the Wikipedia, there are a few issues with the chroot thing I mentioned:
1. It requires root privileges [Like UAC, might be annoying for some users]
2. A root-privileged program can escape from chroot [Really an issue of user gullibility, as some security problems are]
3. Requires you to copy or symlink in needed system libraries and device files. This is a little inconvenient, but it's not horrible to ask programs to bring their own config files, savegames, and libraries to the place.
4. It's not actually meant to be used as a security measure. It's more of a testing and virtualization layer.
So, overall, it's easy to do and it's probably better than nothing, but it leaves a lot of room for improvement.
And as always, a socially engineered user can just say, "I don't have time for chroots, I'm trying to watch free porn here!" and bypass all the security. Not really a way around this.
You might also try something like:
1. Create a separate user "sandbox"
2. Give sandbox full permissions to his SD card, but no permissions to /home, and read-only or read-execute-only permissions for graphics libraries or whatever is expected to be on the system.
3. Use a su command to run untrusted programs as the sand box user.
4. If possible, maybe log suspicious calls and alert the user.
Again, I don't know a whole lot about Linux, but I think this could work as a basic defense against malware.
Last edited by a moderator:
Hmm.... after reading all this...
Is there or going to be a n00b guide/faq on the many ways to set up your filesystem with advantages and disadvantages, cuz that would be helpful.
I'm gonna have to spend an hour on first page to understand all of this, so yeah.... On top of that, Linux n00b
Is there or going to be a n00b guide/faq on the many ways to set up your filesystem with advantages and disadvantages, cuz that would be helpful.
I'm gonna have to spend an hour on first page to understand all of this, so yeah.... On top of that, Linux n00b
Last edited by a moderator:
Similar threads
