Hi,
I’m a newbie to PortableApps (but not application deployment as I use Novell ZenWorks at work) and I have a deployment question.
I’ve been doing lots of searching on the forum (and Google) about portable applications and how to install / deploy them.
When an application needs to write to the registry, the launcher / wrapper firstly makes a copy of the registry key, writes the new settings, launches the application, and then writes the original settings back to the registry.
My assumption here is that PortableApps runs as the currently logged in user. I work for a University and the majority of users have very little rights over their workstation. Therefore if an application requires write access to HKLM, and the user running the application from PortableApps has no rights to HKLM then the portable application will fail?
Thank you for developing PortableApps, I really like it.
Regards,
Chris
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
The apps on this site are configured to run on limited access machines.
HKLM (HKEY LOCAL MACHINE) is restricted for most of these accounts, but if the app is not actually installed, it shouldn't write there. It may write entries to HKCU (HKEY CURRENT USER) but John's installer should remove them upon exit.
If you want to see for yourself, try this at home on your personal system.
First, get the RegShot app here:
http://www.portablefreeware.com/?q=regshot&m=Search
(This is portable, too)
Use this to get a baseline snapshot of your registry, and the start up all your portable apps. Leave them open and take a comparison snapshot. You should see all the keys in use.
Try this again, this time after you've closed all your apps, and you can see if any residual keys are left.
I made this half-pony, half-monkey monster to please you.
Thanks Solanus for your quick response.
I was thinking through the design issues when trying to convert a “normal application” into a “portable application”. As an example MS Office (although I am not actually trying to make this portable, it was just an example of a more complex application).
I know from my own experience that MS Office writes to HKLM (as well as HKCU). Is my assumption still correct that since MS Office needs to write to HKLM (and if the user has no rites to HKLM) then the install / application will fail?
Terminal applications often make use of an interceptor that redirect registry settings to a local text file that the user has write access too. Dose PortableApps work in the same way?
At the moment I’m just trying to understand the limitations of PortableApps and the type of applications that will / won’t work in that environment.
Many thanks for your help,
Chris
registry settings arent redirected.
As you said, it just backs up the old ones, runs the app, saves the app-specific keys and puts the original back.
You could though let tha launcher check what user type is running the app (restricted, guest, admin, whatever) and only let the app being run if the user has enough privileges and make a popup if not...
but i dont think thats what you want...
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
The "launcher" for Portable Apps does what it can to make the application happy, but obviously if it can't write to HKLM (or create files in C:\windows) it may not be able to. It all depends on the application. If the application absolutely requires the ability to write to HKLM, or if it refuses to run unless certain entries are found in HKLM, then there's not much we can do about that.
I think I've seen where some of the PA packages try to write to HKLM, but they fail gracefully -- that is, if they can't, they shrug and go on about their business.
So we have two cases: programs that don't try to use admin privileges, and those that do but keep on going without it.
So it is the third case that is being considered, those that fail if they cannot use admin privileges, or if certain registry entries or files are not present.
The example that raises the most concern hereabouts is TrueCrypt. If it has been run once by an administrator on a particular machine, admin privileges are not required by those who run it subsequently (the driver has already been installed the first time it was run). This case might be extended to your situation: if your software admins use GP or Zen or something to do the preparation (install drivers, make registry entries) then this sort of software is likely to run. It might not run if someone plugs the USB drive into a random machine somewhere else, but if you have control over your network, it might not be too difficult to set up an accommodation on all machines without jeopardizing security or the proper working of the network.
The last case is software that refuses to run unless it has admin privileges, whether to write files in restricted directories or make entries in HKLM or change security descriptors or whatever -- and I don't mean just at install time, but every time it is run. My position is, why would you even want that kind of poorly behaved software running in your system?
Having some sort of virtualization that allows the user to have admin privileges in an isolated sandbox would be good, for a variety of reasons, not least of which is to isolate the guest user from nastiness on the host computer. But most if not all of the software on this site works just fine without it, so it isn't a huge priority at present.
MC