I'm trying to figure out how to install software when the PC reboots Note that this is on machine startup, not user login. Anyone have any suggestions? Google searches just return how to set programs to start on user login. That's not what I need.
You have a few puzzle pieces to unravel here:
Choosing a mechanism for running on startup prior to user login. For this, the fact that your task is installation of further software doesn't matter. A "service" is the usual way to do this, although for example antivirus software tends to use device drivers.
Automating scheduling your code to run at startup. If you chose a service in the above step, this means using the Service Control Manager API.
Actually doing the work, without having an active user login session. Services run in an environment where there is no UI available, the user registry is associated with a service account and not any real user, etc. Other than that, code runs normally (you can load DLLs, access files and directories, etc). Permissions needed by your installer may also become a problem and cause you to modify the service installation options in step 2.
Many Windows programs are able to run an update when they start, without an admin prompt. Similarly, my program needs to update itself, without any user input. Any user who logs in needs to be able to use the program.
My program can already find new updates, download them, and run them, but the NSIS installer/updater requires admin rights.
What would I need to do to implement this using Free Pascal and NSIS, short of giving all users access to the installation directory?
Is your application that important that you need to do this? How often do you actually plan to push out updates?
Most applications can probably get away with just elevating with UAC each time it needs to install a update.
If you absolutely feel that you need to "bypass UAC" then you can do what Firefox does; install a NT Service. You don't start this service in the installer but you must call GetNamedSecurityInfo+SetNamedSecurityInfo so you can add SERVICE_START access for the Everyone group to the ACL. Your application running as a normal user can then start this service when there is an update and the service does the updating.
From a security standpoint there are some dangers here because the service runs with full access to the system so you must make sure that your updates are signed so it does not become an easy to use backdoor if someone is able to pull off a man in the middle attack.
I personally think that you should consider doing per-user installations if your program is not too big...
Looking for suggestions on how to go about the following, i.e what would be the best language to do it in etc, third party tools are a no :(
I've been tasked to create some sort of windows shell/command line interface that will allow a standard users to install a specific set of applications (configurable by administrators) (installation requires Admin/UAC elevation) due to security restrictions the user cannot have elevated privileges so they'll be able to run the shell as a standard user and it would have hidden/encrypted credentials built in to run the installs as.
Some of the requirements are as follows:
It would need to work on Server 2008 R2, 2012 r1 and 2012 r2
The credentials used to perform the install would have to be hidden (encrypted) from the end user.
Ideally it could work by us providing some config to it prior to handing that server over to the customer and limit what it could be used to install to a particular .exe or .msi (so we know of a need to install an app, we are advised of the name of the install and can logon and can enter it into a form maybe so only that app can be installed, then hand the server over to the customer who runs the same utility or shell extension or whatever and can then install their app.
Even more ideally it was more intelligent than that and some means of ensuring any .msi was indeed installing the application that the msi name related to (seems unlikely but just in case a normal user created an .msi to grant himself further admin access as per http://blogs.technet.com/b/fdcc/archive/2011/01/25/alwaysinstallelevated-is-equivalent-to-granting-administrative-rights.aspx )
Ideally its lifespan would be limited in terms of time (unsure if this could be for example to x number of days).
Any pointers on how to go about this, seems like a good challenge :)
Thanks for reading all that!
Mike
Thanks for the responses,
I managed to do this in C#, with no prior experience in the language :)
The application has 2 parts to it, a GUI and a service. It works by having the application send an install command via IPC to it's counterpart elevated service. (Thanks Hans Passant for pointing me in the right direction there). The service initiates the installer under it's own elevated account but displays the installer GUI on the users session. Files are HMACSHA1 checksum validated prior to install, on both the app and the service.
Thanks,
Mike
If a user requires the ability to install application in the Program Files folder, then instruct the domain administrator to give Full Control of the Program Files folder to Everyone:
Just because the default setting forbids standard users from modifying programs, doesn't mean you have to keep it that way. Windows is a secure operating system that gives you the capability to keep it secure.
If your administrator only wants some users to be able to modify the contents of the Program Files folder, then only give that permission to certain users.
The better solution is to re-design the applications so that they do not install in a (by default) protected location. Have them instead install in:
%APPDATA_LOCAL%\Contoso\Frobber\Grob.exe
e.g.
D:\Users\Ian\AppData\Local\Contoso\Frobber\Grob.exe
A user is always allowed to write anything in their own profile folder.
Is there a way to find out what privileges my application needs in order to run in a Windows 7 environment?
I have a Delphi application that is using BDE and ODBC for database connectivity. This application works on most computers with Windows 7 running on a normal user account. However on some computers it only works on accounts with administrative privileges and is not working correctly on normal user accounts. I suspect it's a permission problem. The computers also are running in Active Directory.
I tried to find some informations using Process Monitor from SysInternals, however the output for me is too advanced. The process monitor log for two runs of my app (1. successful with administrative rights, 2. unsuccessfull on normal rights) had over 22k lines and i could not find the answer (needle) in the process monitor log (haystack).
What could i do to determine the privileges that my app needs in windows 7?
Use the Standard User Analyzer from the Microsoft Application Compatibility Toolkit.
The Standard User Analyzer (SUA) tool and the Standard User Analyzer
Wizard (SUA Wizard) both enable you to test your applications and to
monitor API calls in order to detect potential compatibility issues
due to the User Account Control (UAC) feature in the Windows® 7
operating system.
UAC, formerly known as Limited User Account (LUA), requires that all
users (including members of the Administrator group) run as Standard
Users, until the application is deliberately elevated, by using the
security prompt dialog box. However, not all applications can run
properly with the Standard User role, due to the application requiring
access and privileges for locations that are unavailable to a Standard
User.
Aaron Margosis has a tool called LUA Buglight that is designed to help track down issues related to privileges.
You can download the latest version from this blog post:
LUA Buglight 2.1.1 with support for Win7/2008R2 SP1
It is similar in concept to the MS Application Verifier. However, in practice I found LUA Buglight much easier to use and understand. Same with ProcessMonitor. It will monitor your process in a similar way but only report actions that failed as a normal user but succeeded as a admin user.
There is no documentation but it is simple to use. From the main GUI window select your Exe and let the BugLight program launch it. You need to be running in an Admin account with UAC enabled. Run your program though the steps that fail when you are not an admin. When you are done click on the Stop Logging button to see a report that lists what calls would have failed without admin rights.
Update: Since development machine has moved to Vista, i now automatically test as a standard user. And with XP being phased out, this question isn't so relavent anymore.
Since the Windows 2000 logo requirements, Microsoft has been requiring that applications run as standard user. Like everyone else i always ran my desktop as an administrative user. And like every developer: i log in, develop, run, and test as an administrative user.
Now with a new push to finally support standard users, i've been testing my applications by running them as a normal user - either through RunAs, or having my application relaunch itself with normal rights using [SaferCreateLevel][1]/[SaferComputeTokenFromLevel][2] if it detects it is running as an administrator. i quickly see how specacularly some of my apps fail under Windows XP as a standard user (due to my own stupidity). i also see how the same applications work fine under Vista (thanks to it's numerous shims to fix my bugs for me).
Aside: It's ironic that applications are more likely to run on Vista as a standard user than on XP.
The question is do you test your applications for standard user compatiblity? Do you develop as a standard user on XP? Do you ignore standard user access and hope for the best?
i tried, as a bonus, to have my app relaunch itself as a limited user (rather than normal user). It doesn't even come up - Windows says it failed to initialize. So there an area of future research on my part: making the app even support limited user.
i specifically referred to standard users on XP rather than Vista to enforce the truth that Vista is no different from XP as far as compatibility is concerned. And anyone who says their app fails on Vista must realize it also fails on XP.
I'm going to point you to Crispin Cowan's "Best Practices for Developing for Windows Standard User" talk. It's well worth watching.
If you want to sell your application to businesses then yes, you must test your application running as a standard user. If your application can't run without administrative privelleges, that's going to doom any sale in to a business.
Even in the home market, plenty of people can and do use limited users to go about their daily activities; I know I do.
Even administrative applications that do legimately need administrative privelleges should behave sensibly when running as a limited user. They should popup up a dialog informing the user that administrative rights are required to complete whatever task it was that they were attempting.
The best way to build software that respects these limitations is to develop your software under a user that has limited privileges. That way, every time you develop a feature you're implicitly testing whether it will work in a limited environment.
None of this is hard, it just take a degree of discipline - just like all quality assurance procedures do. People have been developing as non-root users on *nix for decades. Windows development is behind the curve in this respect.
Crispin, in his PDC talk, made a very good point, one that i had never considered before.
Google Chrome installs as a standard user: it installs in the per-user folder, without needing a UAC or OTS prompt, and everything is user friendly because the install is so easy. Unfortunatly, it is installed in a per-user folder, where the user can modify it.
Put it another way: malware can modify the Chrome exe.
Chrome would now become the biggest target for any mal-ware. And if some malware does modify it, Chrome is now sending your usernames, passwords, and credit card info back to home base, because that's what the new Chrome exe does.
That is why you sometimes want applications installed to protected locations.
Edit: The entire Microsoft "Click Once" deployment inititave suffers the danger.
I run on XP as a limited user almost all of the time and as the default. (On Vista, I use an adminstrative account and rely on UAC.)
I develop as a limited user. There's very little in Java and Visual Studio development that requires any more privilege than that.
If I need to run something under the limited account but with administrative privileges, I use a MakeMeAdmin (renamed and tuned as ConsoleMeAdmin) .bat script that creates an administrative console session.
If I really need to be an administrator in order to do installs and do first-time-runs so my security software can condition itself to allow network access to the new code (or not), etc., I will elevate my Limited User Account to Administrator long enough to get all of that done, then restart the account as Limited User again. Other than for Windows Updates, I do all of my downloads as a limited user and then install off-line after elevation to Administrator.
Because I only have a small workgroup LAN with no Active Directory, the only useful account types are Administrator and Limited User on XP. (I tried power user when I first began using XP but found that I could do without it and I prefer what that teaches me about not depending on special privileges in code I build.)
[PS: I also have Data Execution Protection (supported in hardware) active by default on my XP system, and you'd be surprised what that turns up.]
In the business environment most users are standard windows domain users.
To ignore standard user compliance tests is a really bad move.
And you will get each domain administrator that has to install your application very angry and they will go to your competition.
IMHO developing in an administrator account is not only unnecessary, but also highly dangerous! Suppose you check something on the internet while developing (stackoverflow comes to mind) and you catch some malware - history shows that this is far easier than you might have thought, e.g. through banners. As an administrator this malware will infect your computer and you might never get rid of it. It can even be a danger to all your development work (think of industrial espionage)!
If you have to run/test anything as an administrator, use either runas or even better virtual machines - that way you can use separate systems with defined behaviour (lots of problems with Windows software come from libraries that are of course available on the developer's PC, but hardly anywhere else!). In times of Microsoft Virtual PC and VMWare Server (both free) there isn't even an excuse due to high prices for virtualization software.
I've developed some Windows apps some years ago and besides their installers NOTHING ever required administrative rights. The run-time settings always belong to the user, not to the machine.
And yes, I run Windows XP as normal user at home too, as do my family members (parents etc.). Sometimes a crappy piece of software needs write access to their installation folder, but 95% of all installed apps run fine out-of-the-box by today.
Yes, we test that.
Probably the simplest, but most abused, rule is that you shouldn't do anything that requires write access to your program's install folder. Instead, there's a special folder called Application Data for that kind of thing.
Yes, and I took the general advice that its much easier to get your application to run on Vista if it runs ok on XP as limited user. To achieve that, and know if there were any problems running as limited user, I used LUABuglight.
I generally don't develop as limited user but only log on as limited user for testing.
The number of programs that require Admin rights and write to their own Program Files folder is amazing. To be honest, I've found very few programs that run correctly as limited user, from any software company, big or small.
Anyone else find it funny that Windows developers think its normal to run as Admin (apparently), but Linux developers pretty much never run as root?
As an old-time BOFH I will rain fire and ugly words over anyone asking for elevated rights for their client-side applications to run properly. It's just out of the question, always was ever since around 2001-2002 when we switched from Win9x to XP (sic).
As a newly born developer in a place where everyone on XP is a local admin by a forced group policy and changing it seems to take time and noone is especially inclined to start either - I've installed the RunAsAdmin shim that lowers me down to a normal user for most tasks including developing - much like in Vista. Recommended if you're stuck as a local admin on XP ^^