Brief video: .PND packages in action
November 10, 2009
Posted by: gruso
.pnd files are the format that our Pandora applications come in. It’s actually a self contained package of files, containing everything a Pandora app needs to run. It’s much like an .iso (what’s an .iso? It’s like a .zip, but it’s not compressed, and you don’t have to unzip it. What’s a .zip? Stop it!) In practical terms, a .pnd is an executable. Click it and it runs.
In a nice visual addendum to the recent libpnd article, Skeezix demonstrates Pandora’s easy-as-pi .pnd system in action.
Not the most exciting video ever, but its pretty cool to those of us building this stuff
- insert SD
- .pnd files (a bunch of them) auto-recognized
- double-tap with finger on the screen, launches an app
- eject SD
- .pnd files automatically vanishNo installation, no muck, no leftover files, nice and clean and piece of cake.
jeff
Jeff (Skeezix) loves a bit of forum action, so there’s plenty of Q&A happening on the boards if you’d like to know more.
Frequently Asked Question: What’s a .pnd?.pnd files are the format that our Pandora applications come in. It’s actually a self contained package of files, containing everything a Pandora app needs to run. It’s much like an .iso (what’s an .iso? It’s like a .zip, but it’s not compressed, and you don’t have to unzip it. What’s a .zip? Stop it!) In practical terms, a .pnd is an executable. Click it and it runs.
That was pretty slick.
Does physically ejecting the SD card automagically unmount it?
Furthermore, does physically mounting the SD card automatically eject it?
lol.
though the first post does really have a point and beyond that does pandora angstrom allow hotplugging of all usb and sd devices.
I imagine that if you physically mounted the SD card by, presumably, laying or standing on the Pandora then yes, the SD will be ejected. At some velocity no doubt. :p
heinhin, nice
but did you see that ?
http://gizmodo.com/5401275/new-icontrolpad-prototype-controls-the-iphone-with-dual-analog-nubs
this is the unofficial pandora blog.
It would be great if it was approved by Apple and you didn’t have to jail break your phone just to use it.
Wow ! With this the iphone and itouch is now..the ultimate game console….
2nd most ultimate. I won’t be having you upset the locals.
you do realize that I’m the one hosting this blog right
NO WAY!! You can’t be the real atomicthumbs? YOU MUST BE TROll…
I really hate this system if the .pnd files do not require being given executable rights.
If the files can be run without being given execution rights, then this is an enormous security flaw.
I assume your point is that users browsing online with their Pandora could potentially download an unsafe .pnd file and it would harm their Pandora. However, there is never going to be any personal data on a Pandora because it’s a gaming hand-held, so there is no risk for personal information being stolen. Also, the Pandora is un-brickable because of its firmware bootloader.
That aside, there is ALWAYS going be a trade-off between security and ease of use. This .pnd system makes applications easy to move around and use; you can share apps with your buddies by passing around an SD card. If the potential risk is that I might go online and download a malicious .pnd and run it, well that’s a risk I’m willing to take (especially because I’m not an idiot).
There doesn’t need to be a tradeoff between security and ease of use here. All that would need to be done is have a prompt asking for you password the first time you launch the app. After that it would have executable rights, but before that, it would need your authorization.
Besides, malicious programs can do more then steal personal information. How would you like to launch “marioclone.pnd” only to find that it just deleted all of your save files?
You don’t consider that to be a trade-off? To me, having to re-type my password every time I opened any application would be a huge pain in the ass. Again, that’s the trade-off.
Yes, you can do clever stuff like hash the application and only ask for a password when an application is launched for the first time. It’s still an inconvenience, and that’s my point. I’m not saying it’s a bad idea, I’m just saying that it’s not as though the developers blindly implemented this system without any consideration of the security concerns.
I forgot to mention in my note, but asking for a password still wouldn’t stop “marioclone.pnd” from deleting your save files. If you ran it unknowingly, then typed your password, nothing has changed.
This.
This is how Microsoft tried to fix their security, by asking you everytime if you actually wanted to run something. It didn’t really fix anything: now people download “screensaver.exe” and “nakedpictures.jpg.exe” and just click through the warnings. The exact same thing would happen with the Pandora: Download mariocloneA, enter password, stupid game and delete; download marioCloneB, enter password, good game and keep; download marioCloneC, enter password, BAD GAME ALL DATA GONE!
Asking once or asking every time, it doesn’t make a difference: if you are running something from an unknown source you are taking a risk, and asking if I’m sure I want to take that risk before actually doing it will do nothing but annoy me.
What I am suggesting is standard *nix procedures. I’ll have you know that it does in fact work, as linux security is far better then windows security. UAC only stops 1 in 5 viruses from running, while unix permissions stop all viruses from running.
They also prevent other people from running malicious code on your machine (no password), and stop files from automatically running. This also isn’t necessarily an issue of downloading and running on your own. You might visit a pandora fan site, only to find malicious code has been downloaded and run on your console.
I don’t know about you, but I plan on using my Pandora (when it finally arrives) as a UMPC as well as a gaming device. So while I won’t be doing any bill payments or viewing top-secret documents on it, I will have some data (email, personal files, whatever) that I would prefer doesn’t get compromised or deleted out from under me.
A few points to consider:
- This is open source. It’s being released in a functional state, and it’s expected that the community will add to it. If security becomes a concern, we can fix it.
- This community has used .gpe executables for years without security measures, and without any issues. Admittedly Pandora is attracting a more diverse userbase than the GP machines (which perhaps adds the potential for mischief) but it’s still a very small community. Problem apps will be reported and stamped out quickly.
- We won’t be getting our apps from dark corners of the internet like hotpandawarez.ru. The official file archive (covering Pandora/GP32/GP2X/Wiz/Dingoo) is a long established and trusted source, with all content approved for listing by EvilDragon himself.
I think the question should be: what kind of user is selected by default.
If you have a ‘gamer’ user with limited rights and a different user ‘private’ you can deny access to your private files for the non-private users.
And I think you can work on the pandora in private mode and at the same time start pnd files with ‘gamer’-rights.
Assuming the pandora doesnt always run in root…
Consider — people download _zip files_ of random stuff every day for every device and OS out there, and run it. This is like that, but a hell of a lot more convenient
There is no trade-off.
More to point — nothing is auto-run; they are auto-discovered, but not run. The user still has to run it, like any other app.
Nothing is lost, only gained.
FWIW, SD cards are usually FAT filesystems; there is no executable bit.
++Mason For god’s sake use #! and executable rights for these things, or make them install through a separate installer program with confirmation like a .deb would, or I will keep COMPLAINING about it loudly every day and sending patches.
Executables / installers that work without the X bit, that is the sort of idiocy that happens when windows programmers move to unix (freedesktop.org, gnome and kde, hang your heads in shame for .desktop files).
Also “not compressed”?? I hope you are joking, I’ve never heard of a package format that is not compressed that would be crazy.
“there is never going to be any personal data on a Pandora because it’s a gaming hand-held”, you have got to be joking. I am going to use it as more than a gaming handheld. Are you telling me people won’t check their mail or browse the web on this thing? I know I will.
Even if someone didn’t have personal data on it, maybe they don’t want it taken over by spammers and botnets.
At the very least it needs some sort of pop-up to warn if the thing is not executable, or some sort of “do you want to install this junk” with a delay like firefox has.
apart from that potential security hole while I will never accept, it looks good
Thank You! At least have it require a password for the first run. I demand that if we do not have this in place, that we at least have the ability to stop .pnd files from running at all.
wine used to do something stupid like this with windows .exe files. You don’t have to be an idiot to accidentally press “enter” at the wrong instant in mutt. I and others complained, and they fixed it by putting a simple xmessage – “are you sure you want to run this virus?” something like that.
I don’t see the great difficulty in setting X bits anyway. If you’re using fat on you SD chances are the whole filesystem will be +x anyway, yuk.
uuh, don’t run them then?
Nothing auto-runs.
You dont’ want it to run, don’t run it.
You dfon’t want auto-discovery, turn it off in the config. Piece of cake.
So binaries on FAT systems can run without being given executable permissions?
There are no permissions at all on FAT partitions. Any permissions must be instituted as mount options.
For example, on my Ubuntu computer, every file on FAT partitions that are automounted using HAL has 755 permissions. That is, any user may read and execute any file, though only the owner has write permissions. They could be set to anything, like 000, 700, 311. However, every file on the partition must have those permissions.
> Also “not compressed”?? I hope you are joking, I’ve
> never heard of a package format that is not compressed
> that would be crazy.
It’ s a loop device ! Did you ever mount -o loop anything? Is a standard step when building your own distribution
WHO never build his own distribution by the way???
I think the regular packages are compressed because the have to be build/installed anyway. On the pandora you don’t install it (right?). So you are just running pre-build executables containted in a pnd format so the show-up on your pandora-desktop. Compressing the executable would be silly, it would only slowdown your pandora. Running compressed pnd files would be a nice feature though (pnc files?).
I mentioned it above, you can play with user rights to restricted pnd files from harming your pandora’s private files. Assuming you can change users and the pandora is not fixed to running in the root account.
Its not classy to say ‘this is stupid’, without first looking into why decisions were made. It is not like the thing was just randomly thrown together.
Again, you suck down a gpe file or fxe or the like for existing devices, and you have to run it. You suck down an installer as an .exe file for windows, you have to run it. dmg file for OSX.. you gotta run it. How is this any different?
Its not like the ‘installer is auto run’; there is no installation. If you execute a PND, it runs, just liek downlading a zip file with an .exe in it, for every OS.
Codeweavers ships their wine port as a .sh that runs and installs things; how many linux tools and games come as bin files in a tarball or zip?
How many unix and linux folks are using source or binary repos to suck down things; you think they’re looking at every compile? You go to /usr/ports and cd into the right dir and do “make install”; you use gentoo and pull down something; you use an rpm or a deb; you’re inherently trusting a lot of the chain.
So this system is no less secure than what peopel use every day.
We’re, in our spare time, building a super convenient suystem for a little handheld; we’re not IBM with 700,000 employees.. I think we’re already inventing some great stuff.
You want more.. its open source, have at
–
As to uncompressed; this is a feature, for failsafe. Read the wiki for an exaplanation why. But furthermore, iso is not the only supported format within a pnd.. we have done zip and cramfs and others, but iso is what we’re going with right now, but this is nto to say it will be the only format within. But it has many advantages.
ie: IF you want it to be zip, its much slower to use (mount speed, usage speed), and has less failsafe for when the packager forgets to put the PXML on the end of it (say). With an plaintext iso, we can still backseek to find a contained PXML, for instance.
It goes on and on; but if your’e just goign to shout and try to urinate on others work, without actually mulling it over, from a user perspective, then .. you’re jus screaming for screaming sake. Sillyness
Its not like we’ve been hiding for the last year while devving this stuff; we’re in the forums. You can talk to us.
Before anyone else starts ranting about security, for god’s sake, please read these:
http://pandorapress.net/2009/11/02/libpnd-the-pandora-library-goes-public/ (and all comments)
http://pandorawiki.org/Libpnd_hub
http://www.gp32x.com/board/index.php?/topic/50234-libpnd-the-pandora-library
http://www.gp32x.com/board/index.php?/topic/50363-aight-ill-post-it-then/
If you then have some input to offer, drop into the forums and say “Hey guys, I have these concerns, how about [.........].” That’s how it’s done. That’s how dflemstr helped improve the PXML spec. Don’t bitch. Help fix.
Accusing guys like Skeezix of idiocy is ignorant and rude.
re: compression, I may be wrong, I’ll double check my facts.
All right, I read through all of your links. It looks like I can prevent the .pnds from running just by getting rid of pndnotidyd.
From what I understand from the wiki, a shell script called pnd_run.sh is used to execute things within the pnd.
However, I still think that every pnd needs to be given executable rights to run. This is the way virtually every executable within linux works. Yes, the security flaw is small, but in my opinion it is bad practice not to follow this trend.
I didn’t say he’s an idiot, but if someone makes these .desktop / .pnd files which can be clicked and run without the +x bit and #!, or even a confirmation, I think that is an act of idiocy. I suppose I’m guilty of such acts myself on a daily basis.
I’m sorry, I really feel strongly about this. It’s much easier to design it right in the first place than to go back and try to change every stupid .desktop file out there. If you let this go in spite of being warned repeated by me and others, you richly deserve the title of idiot, and I will regret donating to the pandora dev fund.
@Sam Watkins
“I’m sorry, I really feel strongly about this. It’s much easier to design it right in the first place than to go back and try to change every stupid .desktop file out there. If you let this go in spite of being warned repeated by me and others, you richly deserve the title of idiot, and I will regret donating to the pandora dev fund.”
If you feel that strongly about it then help improve the PND spec by coding, not bitching. Alternatively, don’t use PNDs, install your own OS, whatever you want.
I don’t think you’re going to get much extra security by implementing a password for running PNDs, if you’re running a malicious PND without knowing the damage it can cause then you’re going to give it the password anyway. What exactly do you hope to gain in security here? Also note that these executable rules apply to PNDs, the rest of your Linux system is going to be just as secure, so unless virus writers start packaging viruses as PNDs you’re not missing out on security are you?
Personally, I think it would be worth adding an OPTION for password activation of PNDs, just to stop the moaning, but if you want that option, CODE IT!
It seems that I had misunderstood what a .pnd actually is. The .desktop system is brain damaged because it doesn’t require +x on the .desktop files, which are effectively little clickable shell scripts. But as you say you’re not responsible for that. This .pnd format is a filesystem not an executable in itself. I think I would prefer to click the .pnd first and then click whatever icon inside it, two steps, but others will prefer one step, and this is configurable and/or hackable. I don’t want password activation, I disable that on my linux boxes anyway. So I’ll forget about this until hopefully one day I will actually get a pandora and then I’ll see whether I like it or not or want to hack it or not.
We didn’t invent the whole .desktop system; its a linux and unix specification. We just read the pnd and rop out a .desktop, which pretty much all desktops can use. Thats how the _standard_ is defined. We didnm’t invent it, nor is it particularly bad. I’m not sure I see the different between a user hitting “please pull down this add-on in firefox, one click”. Linux Mint or any Ubuntu or Debian style installer — “find me this tool, and install it”. In this case it would be user going to a known repository, downloading a file, and copying it to a specific set of locations on SD or device, to make it available. Its not like every pnd file on someones computer will be shown, and the user had to go and get it, and he has to run it.
If someone is going to make a malicious pnd file, they coudl jsut as well have made a malicious gpe etc in previous syetems; they could mark it all exedcutable or whatever.
If you’re talking more about _signing_, and authentication servers and such, then sure, it could be built on; a reputation system will presumably be in any good repo; an upload verification/screaning systemm. Thats all out of scope for packages.
I’m genuinelky confused why you think this syswtem is worse than what peopel use every day on every OS; if you an enlighten me, I would like to know .. I don’t generally miss the obvious
I think I understand the problem here. What Mason and others are saying is “Executing without the +x bit set is bad.” And they would be correct. Execution without setting the +x would be bad, IF the PND file were being executed.
PND is not an executable. It is a package, with information linking to an executable inside it.
Have you never loop mounted an ISO before, and then executed a file within that ISO? Do you think the ISO file itself should have the +x bit set in order to execute stuff mounted from inside it? I argue you do not, and the experiments that I just did tell me that doing so would not be normal.
So to reiterate, PND is not an executable, and setting the +x bit for it would not make sense. It is a package which contains an executable. The PND notify daemon does not execute a PND, it simply mounts the package to a hashed directory, and then provides a link to the inner executable in a .desktop file so it can be clicked to run.
Forgive me for misunderstanding, but I thought that the PND acted as a delivery mechanism for binaries.
So, perhaps this is what I should be asking.
Can the PND execute binaries that do not have the +x bit?
This is a no. The PND is just a package, it contains a bunch of files, and a pxml file. The pxml file indicates which file inside the PND is *the* file that is supposed to be run, and creates a link to it on the desktop, and that’s where it stops. When you click the link, it is up to the OS to decide whether it can or cannot run that executable. If the file within the archive does not have the +x bit set, the OS will not execute it.
To be precise..
A pnd file is .. a container + copy of PXML.xml + optional icon png file (where + means catenated)
The container is currently .iso, but in the future others will be supported (and determined by checking inside the PXML for package-type, or perhaps using libmagic on the header bytes.)
The iso includes a complete filesystem (ie: subdirectories and all), and should have the PXML.xml (and optional icon) in the root.
If using .desktop type system, pndnotifyd daemon will detect what .pnd files are available in the search paths (configurable), and create .desktop files referring to the pnd files. (libpnd may be used for launchers that don’t wish to use .desktop files.)
The .desktop files are shown in standards compliant desktops (such as xfce, e17, etc) and the Exec line points to pnd_run.sh (configurable.)
pnd_run.sh knows how to mount a pnd-file, set it up so that writes back to it will be redirected to appdata path, and all that business.
Lastly, the OS does in fact have to honour the launch of the referred to binary within the pnd.
I forget, but probably everything within the file is executable as far as its concerned. (its not like its a ufs or ext2 filesyste.)
But recall.. nothign is auto-run; the user has to put the pnd in the right place, and has to actually run it. What is so wrong with running stuff the user wants to run?
Security issues are when stuff runs the user does not want to run
I’m still confused about the ‘root concern’ here.
Can someone spell it out for me?
My stance is — since nothign is autorun, we’re pretty okay.
Saying “needs +x just because its so!” doesn’t clarify for me; why specifically do you want every pnd to ask a ‘run me password’ first time through?
Why is it wrong to be at least as secure as every other OS (Unix and Linux included.)
Am I missing something, or is this a case of ‘we think it’d be better like this, even though no one else does it’, which would be fine and we can debate the merits of that. I don’t see it as any worse than anything else out there, so dont’ see why it shoudl be freaking out a couple of people. But I really want to know if I’m just missing it
Windows: download a zip, pop out the exe and run it.
Linux: download a bin file and run it; use dpkg and pull down a binary file to run it (like is done on most distributions.. Mint, UBuntu, etc.) Or even a source pull — not like anyone is checking to ensure all those packages are legit or not hacked half the time. People just install, see icon, and run. No adsking the user a password before running..
OSX: dmg includes an executable dir-bundle, or just a zipped dir-bundle. Double click to run.
You got me totally confused how this is any worse, or if you’re just holding us to a higher standard than the entire world of a million devs who’ve never done better?
Looks sweet! Looking forward to developing for Pandora one day!
Very impressive work!
And it looks like XFCE is going to be the default WM! Good for me, then I don’t have to switch
People are actually worried about security on a device with a max potential userbase of, say, 75,000 – 100,000 over the course of it’s five year life-cycle?
Nothing really wrong with worrying about security or design; its better to get it right up front. But yeah, most buyers will never put any data in NAND (likely?), instead just runing emus and apps and homebrew games off SD, and not fretting it. The pandora is an unliekly vector for attack against other machines, since as you say it’ll be a low population device.
But we dont’ mnind criticism; what I personally mind is criticisism as a DoS attack — it is easy to lash out without thought, then make someone else spend lot sof effort defending, when all the info is out there anyway
Its the ‘environmentalist attack’ pattern — “all of these options are no good”, as opposed to “let us take a decent system, and try to come up with a better system, since we’re all human”
jeff
Dude, they’ll worry if an egg is not white. People think its a huge security risk but in reality they have any and all options open to them, so they pick the most convenient and pick at it until its no longer convenient for anyone, then they move on to the next annoying task.
They do this because it makes them feel secure.
I, on the other hand, don’t care either way because I’m good enough to fix whatever I don’t like. Other’s just like to complain.
Its amazing how much feedback got posted _here_, rather than on gp32x forum. Pandorapress has really taken off
jeff
More clarity of thought here.
lol
are they dynamically (save SDD space), or statically linked (waste of SDD space) with the contents of what IS present in flash 512MB memory?
eh? Up to devs, but the suggestion is..
- apps should dynlink to libs on the device, where possible; if a lib is not on the device it can either static-link it, or dyn-link and include it with the app, or try to get the user to install the lib*
* popular request libs could be ipkg’d installed right into the firmware; so if a couple apps use a dynlib they include, and it becomes a priprioty, everyone could patch up and get the lib (say), or include it in the next firmware release
Its a pretty ideal setup that way, imho.
is the shed red enough yet?
I personally think it should be green anyways. In fact, I demand it be repainted. If its not, I’ll piss and moan some more Damn it!
Why is every one starting to sound like Broomfondle and Magic Thighs?
Because incessant arguing and speculation opens doors to a life of lavish punditry unimagined by those unacquainted with Aggressive Philosophizing.
@Skeezix (I can’t reply to the main comment anymore, it has gotten too narrow)
>Linux: download a bin file and run it; use dpkg and pull down a binary file to run it
But to do this, you need to authenticate it first. You must give your password before you install anything. You cannot simply download and run a binary, you must chmod it with root permissions first.
>OSX: dmg includes an executable dir-bundle, or just a zipped dir-bundle. Double click to run.
Yes, and then there are also .pkg files which require your password before they are able to do any writing to your system other then placing the .app in your applications folder.
>Saying “needs +x just because its so!” doesn’t clarify for me; why specifically do you want every pnd to ask a ‘run me password’ first time through?
I don’t see why we shouldn’t be doing what is proper form. If we can execute binaries without having an administrator consent first, then the security of the system is compromised. It *is* possible to have binaries be placed onto your system unknowingly to yourself. Perhaps a “friend” put one on your system.
So you enter a password to download a bin to your machine and install it; you can arbitrarily run it on linux.
Here, we don’t have an install; you still have to download it (browser/etc), and copy it to your SD and put it in the right place, which is a few swteps that a real human needs to do, pretty much.
But execution, is, just like on every OS, not needing a password. We’ve just removed the install step, _made life better_. Thus nothing differs to Linux/Unix/Windows/Mac/etc.
More to point, you said:
if we can execute binaries.. well, you certainly do not need to be root to run a binary on any OS. You don’t even need to be root to install them into your own account. You need root to modify the filesystem and install them there .. but we’re not doing that. We’re not modifying any filesystems.
No apps are being placed onto your system unknowingly; they’re on your SD card, and you put them there
I suppose a security-level config could be had, and something that said ‘wait, during discovery some new pnd files have been found, do you wish to authorize them’ could be done, but then you end up calculating md5s on everything (Since you can’t trust unique-ids) and storing that.
It seems ‘way too far’ in my book, but it would not be hard to do; feel free to patch it in. Thats an ewasier way to go about it than some of the other ideas that’ve come up.
ie: need a config file to map md5 to ‘been there, done that’ status; need to add an md5 calc tool to the distro if not already there; need pnd_run.sh to grep out the line of interest in sed file and pop up the confirmation/cancel dialog; on confirm, it can alter the config file to note that this md5 is now permissible.
Really though, your problem is with freedesktop and all the spec groups that define how these behaviours should work. You stick a .desktop file on an SD or CD or usb-key and pop it into any modern distro, and the stuff is fully executable just like that.
We’re no differnet than everyone else out there, but we’ve made it a heck of a lot more user friendly.
To add –
I think theres a question of ‘motivation’ here; you’re assuming that because when you use (say) apt to suck down a package, you’re asked for a password, that they did this to protect you from the app. In fact, that really is only done because you need root to modify the system. (Evidenced by the fact you can run anythign you want any time pretty much; they don’t protect you from just downloading and running an app any old time. Secuerity in unix has always been relatively haphaard due to the long history of the systems.) ie: If they really worried about protecting you, they’d do a lot of thigns differently. Instead, the distros try to protect you from bad installations, and never bad running. We’re skipping installation, so we never sweatedf that much.. we’re “equal” to other systems, plus easier to use.
But that said, I am not philsophically against helping you authenitcate first-runs of a ‘new app’ (newer pnd version, whatever.) Coudl be done, as above.
I think we can close this conversation by saying — we’re at least as secure as others, and easier to use with a wicked awesome system. We’re in a ‘feature lock’ more or less now, since we want to ship.
A tighter system like that could be added, and is not a bad idea!, without breaking anything, as mentioned above, and could be made optional for those who don’t want the performance hit of running md5 or crc32 on every pnd every time they want to run it.
Its odd to be in a spot though, that a couple of guys in spare time are building somethign, and held to a higher bar than all those who come before them. I suppose thats a good thing — should we always not strive higher? But damn mate, it certainly does not make something lousy if its as good as everyone else
ie: your first few posts are pretty accusatory.. “this is crap security!”, which as I’ve pointed out is pretty untrue, so I think you need to be careful; we’re among peers here, not faceless dudes you want to go around dissing just for a lark
Anyone, enough time on this thread (for now). Cool?
jeff
This argument is ridiculous. You are not magically granted immunity from malware just because you have to enter your password before the program is allowed to run.
Thought experiment: Somebody makes a harmful program that wipes your SD card. They call it “Halo 5: Master Chief Saves Christmas”. You download this program and load it onto your Pandora. You double click the icon in anticipation of the Halo-y goodness to come.
If the system does not ask for a password, the program runs and wipes out your SD card.
If the system _does_ ask for a password, you enter it, and the program wipes out your SD card.
All you’ve done is delay the inevitable for a couple seconds. Password authorization is security theater. It doesn’t stop you from running malicious programs if the program has tricked you into thinking it’s benign. All it does is give you an annoying reminder of how “safe” you are every time it forces you to enter a password to run a program which may or may not be hazardous.
> It *is* possible to have binaries be placed onto your system unknowingly to yourself. Perhaps a “friend” put one on your system.
How does a password help you here? Either you’re going to go “I don’t know what this is” and delete it, or “I wonder what this is” and try to execute it. If it has no password protection, it just runs. If it has password protection, then you enter your password, and then it runs.
I am not against improving security if it will actually improve security, but if you’re going to take away peoples water bottles because someone once suggested they could make a liquid bomb (didn’t even prove it, just suggested it) then I am going to totally lose my train of thought.
They run it, or you run it accidentally. And NO, you cannot simply download and run a binary or shell script without first changing the permissions on it, at least on all the distributions I have used.
irrelevant. You’re back to “we should do it this way because that’s how it’s done” and not actually explaining how it will help in this particular case. “The way it’s done” isn’t always the right way in all situations.
You came up with an example where you thought it would be useful. We presented our case as to why the example is flawed. We’re asking you to present your rebuttal or find another example where your proposed password system actually would provide the security you’re looking for.
Dude, you’re so wrong
Create the following on a USB thumbdrive or SD or CD or whatever:
I called it spork.desktop
–
[Desktop Entry]
Name=foo
Type=Application
Version=1.0
Exec=/usr/bin/xeyes
–
Insert into usb port on Ubuntu, Mint, Redhat, anything I’ve tried, including FreeBSD and so on … it shows up as an executable. Click to run, NO QUESTIONS ASKED.
If its a .sh then _some_ distributions will offer to run or show it on filesystems such as FAT. If its a random file, they’ll often ask to run or display it. If its a malformed .desktop (missing the [] header say), they will ask to run or display it. Pretty poor.
If its a well formed .desktop, they will _run it no questions_, and thats Unix and Linux. Same as Windows, Mac, you name it
So…… yeah, security is terrible everywhere,. You _thought_ it was better than it is, but its not.
I’ve _tried_ this stuff.. you, go do it now
jeff
it sounds like Mason wants something similar to Windows UAC.. where it asks you “Are you sure?” for anything you try to do. Quite annoying.
Let’s take a look at my recent downloads. “switchscreen-0.1.1.tar.gz?” Let’s extract that. What’s this file? “togglescreen.sh?” And it’s executable bit is already set? How convenient.
My point is that the executable bit can be set in a tar file, which is how I see most executables distributed for Linux anyway.
What do you think about the new date?
A real Christmass this year for us?
myself, no idea; it ‘feels pretty close’, but theres still a few steps I think to go through. But I’m not involved with the hardware or the like at all, so I can’t really say. We on the sw side are busting our nuts as much as we can so we can be ready though, so that tells you that even we know its getting there.
Still, I imagine Christmas should be possible, or if its a miss.. then close after?
From software side, we’re relatively stable but not crazy comprehensive; I think when it launches, we’ll still have a lot of things we’d like to do, but you have to draw a line. Can refine forever, but better to ship (esp when we’re doing it in our spare time for fun, not being paid or anything.. so we can only do so much in a given time unit right?)
We want our units fast too; we’re getting there. “Soon” is what we all think, but I can’t hazard a better guess
Christmas is impossible. ‘Cuz it’s less than two months from now.