I need to access a network share during the install process, and I also need to edit some registry keys. And finally, I'd like to add some shortcuts to a program that is over the network share.
To edit registry keys, I run the installer with elevated privileges. However, if I do that, I won't be able to see the network share as it is usually created without admin privileges.
There is a way to kill the installer and restart it with admin privileges, and this is fine for copying necessary files, but in order to create shortcuts that point to the network share, I would then need to downgrade my privileges again, in the middle of the Inno Setup step where it copies file, a step which I can't do anything in the middle of.
Any other options for a workaround? The only one that I found was this, which requires a registry edit (fine) and a restart (not as fine).
You can create the shortcut using some command and run it from [Run] section with runasoriginaluser flag.
See How do I create a shortcut via command-line in Windows?
Or do not kill the unelevated installer. Run it only to copy the files. And continue with the unelevated installer.
Also note that you can create a shortcut pointing to a nonexisting file.
Related
I am using NSIS to write an installer for my windows application. After installing the application, an uninst.exe is also generated in my program directory. Later on I need to uninstall my program but I failed to do that in control panel. Therefore I went to the file system and tried to delete the directory. Everything other than that uninst.exe was removed. I've tried changing permission of this file and other methods but it doesn't work.
WriteUninstaller does not set file permissions or any other attribute that might prevent you from deleting it. It sounds like the file might still be in use by something on your machine.
Things to try:
Use Task Manager or Process Explorer to see if there is a uninst.exe process still running.
Use the find handle feature in Process Explorer to find any open handles to the file.
Use Process Monitor to get detailed information about the failed delete operation.
Check %LOCALAPPDATA%\VirtualStore to make sure UAC Virtualization is not tricking you with "ghost" files.
Disable your Anti-Virus.
Reboot the machine and try to delete the file again.
I have in hands a third party msi installer that requires to be executed by an administrator. Im trying to change that so it could be installed by a regular user.
I managed to open it with installshield and changed some obvious settings like:
"Require Administrative privileges"
But in your perspective is that even possible? I´m having a hard time changing settings and configurations and until now i´m not having any success.
Im working with InstallShield 2013 Professional and if it is possible, in wich settings do you think i should be focusing?
For instance, running as regular user im now having a 1925 error.
"You do not have sufficient privileges to complete this installation for all users of the machine"
And i feel if i correct the error, others will appear.
Thank you guys!
It's highly unlikely you can do this because it depends on too many things in the MSI package that can change the system. Any files going to restricted locations (program files, common files etc) or changes to HKLM registry keys will require elevation. MSI installs don't violate security - they don't allow a limited user to change areas of the system that are restricted.
If the environment has group policy/Active Directory you can arrange for the MSI to be deployed from a central location via Group Policy, that's the way people get around this. Otherwise on UAC systems the MSI may offer an elevation prompt that allows admin credentials to be entered.
Otherwise the vendor needs to create an install that can be used by limited users.
Well, Yes i need administrative privileges to write to locations that are shared by multiple users. In the filesystem, this means folders like \WINDOWS or \Program Files. In the registry, this means all of the hives which aren't per-user. That´s ok, i don´t need any of this.
Therefore, i thought it could be possible to change the filesystem to something like [userprofile] and rewrite the program to only use the HKEY_CURRENT_USER.
But i suspect it could be more to it than only this.
My application is not supposed to perform any administrative tasks, so I want a normal User account to be able to run it. Only thing is, my application reads from and writes to a database file; if the user running Windows 7 (Or Vista) installs my app in drive C, the drive's default permission set configuration doesn't allow my app to write data.
How can I allow my app to write to C:, without requiring full administrative privileges?
If the database file exists at install time you can just grant the user write access to the file as part of the installation process (ordinary users do not have this permission by default). If the file needs to be created by the program the user running the program will need modify permissions on the c drive, which is not something that I would recommend.
I'd suggest storing your db file in Documents and Settings / App data / your app / directory. It exists specifically for this purpose. Writing to C:/Program Files is not so good practice. If that's possible in your case, that is.
You need to open UAC (User Account Access) and set security slider to the bottom. Then you can access drive C: as you did in windows XP.
I decided to modify directory permissions in the setup process, so I created an .exe file that changes the permissions of its start-up path, and gives all users access to that path. I simply included that .exe file in my deployment project, and created a Custom Action that would run the file in the Commit phase of installation.
Because the setup asks the user for administrative rights when it is being installed, my .exe also enjoys administrative privileges and can modify the permissions of the installation directory.
In my .exe, I used a Process instance to run the ACL utility shipped with Windows (icacls.exe) as follows:
ICACLS.EXE [TargetDir] /T /C /grant Users:F
(Make sure that [TargetDir] doesn't end with a "\" or the call will fail.)
This gives all users full control access to the target directory.
I could also write .NET code and change directory permissions manually, but I'm a little lazy!
You may however want to inspect your environment conditions thoroughly so that what you do wouldn't become a security hole in your environment; but this was suitable for me.
I hope this helps others who faced the same issue.
The user by default should have write permissions to drive C:, if not, then you will need to change the directory you read from and write to, to the executing directory (C:/Program Files/Your App/) rather than the root of C:
You can get this by
String Path = Path.GetDirectoryName(Application.ExecutablePath);
On some of the devices that I am working on, the \Windows directory is not on permanent storage. That is, once the device is rebooted, whatever was written to \Windows is lost. This is particularly problematic for uninstalling programs since wceload.exe (the Windows CE CAB installer program) generates a .unload file and places it in \Windows. The application can be uninstalled before the device is rebooted, but afterward it can't (the "Remove Programs" tool in the control panel comes back with an error about not being able to open the unload file). So how can I get the .unload file to persist across reboots? Is there any way to control where the uninstaller (I believe it is called unload.exe) looks for the .unload file?
I haven't been able to find any good info on this still. It looks like the path to the unload file is hardcoded so the best I can do is make a backup of the unload file. If the user wishes to uninstall they will have to manually copy the file to the \windows directory and then use the uninstall tool in the control panel. Here is more info:
http://www.generation-nt.com/us/answer/wince5-force-wceload-install-unload-into-nonvolatile-memory-help-87676002.html
You can probably keep the .unload file across reboots by copying it to a persistent directory after installing. This directory may vary per device, e.g. \Hard Disk\ramroot\Windows or \Backup\Windows. It will then automatically be copied to the \Windows on reboot. (Although I am not sure whether such a directory and behavior exist for every device.)
To copy this file you need to execute a copy-statement from a custom setup-dll after the install completes. This codeproject-site has a very comprehensive explanation, with screenshots and code.
Simply re-Install application and then un-install from remove programs in control panel.
I am creating a graphical installer that should run on Linux. Installing should consist of copying files to some places in /usr. Currently the installer is written in Python.
How can I escalate the privileges of my installer when I need to copy files? I looked at PolicyKit but
a) there doesn't seem to be a generic "install files" action-id for PolicyKit
b) of the action ids I can use, I don't think they are standard across distros
I also looked at PAM and I have code that uses libpam but I can't seem to do anything with it. After authenticating my user (by providing username and password) I don't have write access to /usr. I tried changing my user with os.setuid(0) after authentication but I get an error from the OS.
Also, strangely, it doesn't seem to matter what service I provide to pam_start. As long as the username and password are correct I can pass anything I want. I see I have /etc/pam.d/sudo. The below code is simplified, the password is correctly stored in a pam_conversation object and I do pass a handle object.
pam_start("my_user", "my_pass", "sudo_garbage_12345");
works just as well as
pam_start("my_user", "my_pass", "sudo");
That is, they both succeed.
As a last resort I can probably execute gksudo or kdesudo but I don't want to be tied to those programs. Requiring users to invoke my installer with sudo is a (very) last resort.
You might be better off wrapping RPM with a front end that takes the user options and invokes RPM to do the hard work. This also gives you infrastructure for managing dependencies and plays nicely with the existing package management system. If you need to run on a .deb based system (Debian or Ubuntu) you may also need to consturct a .deb and put some mechanism in the front end that works out which package management system is active.
Granting random users access to root privilege is generally viewed as bad form on Linux or Unix systems (or any multi-user system for that matter) as it is a significant security risk. However you do have the option of letting the user install it under their home directory (~/bin) if they don't have root access or sudo permissions that allow them to write to system areas. In this case you can require them to install it as root if they want to install in /usr/bin but permit them to install it under their home directory for their own use if they don't have root privileges.
For a graphical installer, stick with a graphical environment. Use gksudo or kdesudo if they are available, otherwise fail with an error dialog saying they need root. People (newbies in particular) will download your installer and double-click to launch it from their desktop, and you need a graphical way to ask them for their password. You don't want to pop open a terminal on them.
Given that, don't do sudo for them even if they are running from the terminal. Just output an error saying you need root and exit. If the user is already at the command prompt (like I most likely would be), I already know how to sudo or su myself into root if I want to do so. I promise you you will most likely ruffle some feathers if you attempt to make an experienced user root when they can do it themselves.
If you INSIST on doing a sudo yourself from within your installer, for God's sake please force a 'sudo -K' before you do to remove the previous timestamp. If you don't do this, and I have sudo'd recently, you will run your installer with me as root without my knowledge (since I don't expect that to happen). A 'sudo -K' will force a prompt that I can then decide whether I want to proceed as root or not.
The best way in this case is to use su within your program. Redirect inputs/outputs and you're good to go!