I don't really understand windows UAC...
I need for my program to be able to update and add files to a specific directory belonging to a program. This directory may be a subdirectory of an application in Program Files, for example c:\Program Files\MyApp\Data or it may be installed elsewhere.
I believe that if it's under Program Files then my program will be prevented from writting there unless it is running as an administrator AND has elevated it's access rights. Is that correct?
I need to be able to update files in that directory preferable without invoking elevated privileges and with the main application still "protected", just allow access to that one directory. I can't move the Data folder elsewhere as this as it's a 3rd party application I need to interface with.
How is it determined that UAC is needed for folders in Program Files? Is Program Files special in some way or is just permissions? If I were to adjust the permissions on that Data subdirectory so that the user account running the program had write access would that allow my application to update files in that directory without special privileges?
Or is there a better way to achieve this that I'm not thinking of? My update program needs to be in java so getting elevated privileges is a pain. I imagine I'll need to write a C++ wrapper to run the java VM so that i can give that wrapper an appropriate manifest. Not impossible but I don't really want to have to do this.
Try changing your application's directory security settings on-install to allow "Authenticated Users" write permissions.
Usually, when you need both protected and unprotected UAC modes you do the following.
Create two executable (one should be the main one and not require privileges for any operation, the second one should be able to perform privileges operations).
Start the first (main) one using limited privileges.
When you need to perform an privileged operation, create a new process with administrative rights (will pop the UAC window) and start the second application in it.
When done with the second application close it and you'll be back to limited mode.
This is how VMWare Workstation does when you change global settings.
Edit: Changing the permissions on a folder is not a good approach. Is just a dirty hack because anybody can write to that folder and this will just invalidate the role of UAC - after all this is the role of UAC: to prevent unprivileged changes in special folders.
Related
I have a program that needs to run with normal privileges. To prevent piracy, at the launch of our application we launch a License Manager application that needs to run with Elevated Privileges. Upon enquiring with our vendors, the License Manager seems to have this elevated privileges added in its app.manifest file which is necessary to read some kind of Disk ID information, so it is mandatory (we cannot reduce its privilege requirements).
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
The application successfully launches the License Manager if it is placed in a normal folder. However when it is placed in Program Files folder, it seems to close at launch with no intimation.
We also checked running the application with normal credentials without adding the License Manager (it works fine).
Do we need some sort of settings to be changed either in registry or in some other windows settings to enable launching elevated privileged application from normal account. Or perhaps some code snippet needs to be added at the code launch section which can enable this scenario.
We have even tried pasting the folder created in Program Files to the Desktop (it also runs fine).
OS: Windows 7
Please let me know if any additional information is needed form my side. Any help in this direction is appreciated.
My Humble appologies for assuming problem with Program Files Directory.
It turned out that the logs written by the License Manager were being written in the current application execution folder. The problem was caused by trying to write the log to Program Files folder when the appliction did not have the permissions to write a text file to this folder.
The logging logic was shared between the License Manager (from the program we called a function that was defined in the License Manager, which was writing logs) and the application running from the Program Files folder.
We changed the log creation folder to AppData folder. This has caused the applicaiton to launch successfully.
Cause Conclusion:
Writing log file in Program Files folder from an application that did not have admin privilege.
Note: I have added this post and this answer purely to help other like me, in case they dont have a solution in this type of scenario.
I need to create a directory in /var/log using a C program which does NOT run with superuser rights.
This linked question didn't help me!
I understand that the file permissions of /var/log does not allow us to write in it nor do I want to change it.
I use mkdir() to create the directory which fails for obvious reasons.
So, is it possible for a normal (with no root rights) C program to create a directory in /var/log?
My goal: To create a directory using a C program in /var/log without changing the parent's file permission. Should I run my program as root? But I would prefer not to.
Kindly help.
TIA
You cannot programmatically overturn the filesystem's access control.
What you could try to do instead is to use an existing logging mechanism that is provided by the system. For example, journald that comes with systemd allows for per-user logging.
If your program runs as a user, it should only use the user's home directory to store files, wether it being configuration or logging. Think about it this way: What happens if several users want to use your program at the same time?
If your program really is a system daemon, have a look at other software that runs under their own user. They could either have their own logging directory be prepared by the init script that calles them (running the daemon itself as a different user), or they purge their priviledges during startup. An example is httpd, which needs root priviledges to listen on port 80.
I've seen several questions that are the opposite of this; "How do I disable virtualization?" That is not my question. I want to force an application to run with virtualization enabled.
I have an application that ran just fine under Windows XP, but, because it writes its configuration to its working directory (a subfolder of "C:\Program Files (x86)"), it does not work completely under Windows 7. If I use task manager to turn on UAC Virtualization, it saves its config just fine, but of course it then can't load that config.
I do not want to set it to run as administrator, as it does not need those privileges. I want to set it to run with UAC Virtualization enabled.
I found a suggestion that I put some magic in the registry at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags. For completeness I also put it in Wow6432Node, but neither had any effect.
File system is virtualized in certain scenarios, so is your question how to still turn it on when your application does not qualify? It is unlikely possible, MSDN:
Virtualization is not in option in the following scenarios:
Virtualization does not apply to applications that are elevated and run with a full administrative access token.
Virtualization supports only 32-bit applications. Non-elevated 64-bit applications simply receive an access denied message when they
attempt to acquire a handle (a unique identifier) to a Windows object.
Native Windows 64-bit applications are required to be compatible with
UAC and to write data into the correct locations.
Virtualization is disabled for an application if the application includes an application manifest with a requested execution level
attribute.
this may come way too late now, but I am the author of the suggestion you found to activate UAC virtualization, and there was a mistake in my post. The registry keys to modify are the following:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
(notice the "Layers" appended)
so a full example would be:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="RUNASINVOKER"
note that multiple parameters must be separated with space character.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="WINXPSP3 RUNASINVOKER"
--
I'm sincerely sorry that you lost a fair amount of time because of my mistake.
And by the way, let me express my disagreement with Ian Boyd's post. There are places where write privileges should not be granted to everyone, such as this one, since it breaks the base security rule of "System-wide writes should be authorised to privileged principals only". Program Files is a system-wide place, not a per-user one.
All rules have exceptions of course, but in the present case, one could imagine a maliciously crafted configuration file making the program exec an arbitrary command as the user running it. On a lighter side, one could imagine a "mistake delete" by another user, which would make the app fail. Back on the heavier side, application executables in Program Files are often run by the admin, sooner or later. Even if you don't want to, uninstalling programs very often run uninstall executables that are in Program Files. Maybe the uninstall procedure will use that config file which could have consequences if it's maliciously crafted.
Of course you may say, this sounds paranoid somehow, agreed. I did modify some NTFS ACLs in Program Files at the times of Win XP and was able to sleep after that, but why take the slightest risk when the tools are available ?
I found one not very well cited condition where UAC Virtualization does NOT work: when the file in Program Files is maked as read-only.
That is, suppose the file C:\Program Files\<whatever>\config.ini is marked as read-only. When the application try to change it, UAC Virtualization will return an access denied error instead of reparsing it to %LOCALAPPDATA%\VirtualStore\<whatever>\config.ini.
Although I did not found this documented, this behavior is probably done by design, since it makes some sense.
The solution is simple: assure that all files that are supposed to be modified by the application are not read-only (or just unflag all files, since the user will not be able to change them anyway).
You have an application, and you want users to be able to modify registry keys or files in locations that by default only Administrators can modify.
If you were running Windows 2000, or Windows XP, or Windows Vista, or Windows 7, or Windows 8, the solution is the same:
grant appropriate permissions to those locations
For example, if your program needs to modify files in:
C:\Program Files\Blizzard\World of Warcraft
Then the correct action is to change permissions on the World of Warcraft folder. This is, in fact, a shim that Microsoft applied to World of Warcraft. (On next run it granted Everyone Full Control to the folder - how else can WoW update itself no matter what user is logged in.)
If you want users to be able to modify files in a location: you have to grant them permission. If you were a standard user trying to run WoW on Windows XP you will get the same problem - and need to apply the same solution.
Your application is writing its configuration to:
C:\Program Files (x86)\Hyperion Pro\preferences.ini
then you, in fact do want to grant Users Full Control to that file:
So your:
application is not set to run as an Administrator
users cannot modify the executable
users can modify Configuration.ini
Granting permissions is not a bad thing; it's how you administer your server.
There are two solutions:
Install to C:\ProgramData\Contoso\Preferences.ini and ACL it at install time
Install to C:\Program Files\Contoso\Preferences.ini and ACL it at install time
And if you look at the guidance of the AppCompat guy at Microsoft:
Where Should I Write Program Data Instead of Program Files?
A common application code update is this: “my application used to write files to program files. It felt like as good a place to put it as any other. It had my application’s name on it already, and because my users were admins, it worked fine. But now I see that this may not be as great a place to stick things as I once thought, because with UAC even Administrators run with standard user-like privileges most of the time. So, where should I put my files instead?”
FOLDERID_ProgramData
The user would never want to browse here in Explorer, and settings changed here should affect every user on the machine. The default location is %systemdrive%ProgramData, which is a hidden folder, on an installation of Windows Vista. You’ll want to create your directory and set the ACLs you need at install time.
So you have two solutions:
create your file at install time, and ACL it so that all users can modify it at runtime
create your file at install time, and ACL it so that all users can modify it at runtime
The only difference is semantic. The Program Files folder is mean for program files. You don't want to store data here.
And it's not because Diego Queiroz has any insight about security.
It's because it's where just the programs go.
Sometimes machines are imaged with the same Program Files over and over. You don't want per-machine data in your image. That data belongs in ProgramData.
And it's not a security issue.
Some people have to learn where the security boundary is.
there are quite some good points in those other answers.
actually i have upvoted all of those.
so let's all combine them together and add some more aspect ...
the OP mentions some "legacy application from the old days".
so we can assume it is x86 (32bit) and also does not include any manifest (and in particular does not specify any "requestedExecutionLevel").
--
Roman R. has good points in his answer regarding x64 and manifest file:
https://stackoverflow.com/a/8853363/1468842
but all those conditions don't seem to apply in this case.
NovHak outlines some AppCompatFlags with RUNASIVOKER in his answer:
https://stackoverflow.com/a/25903006/1468842
Diego Queiroz adds intersting aspect regarding the read-only flag in his answer:
https://stackoverflow.com/a/42934048/1468842
Ian Boyd states that probably you don't even should go for that "virtualization", but instead set according ACL on those files of interest (such as "config.ini"):
https://stackoverflow.com/a/12940213/1468842
and here comes the addtional / new aspect:
one can set a policy to disable all virtualization - system-wide:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableVirtualization"=dword:00000000
actually i'm enforcing this policy on each and every system that i own.
because otherwise it will lead to confusing behaviour on multi-user environments.
where UserA applies some changes and everything goes fine.
but then UnserB does not get the changes done by UserA.
in case some old crappy software fails then it should "fail"!
and not claim that everything went "fine".
IMHO this "Virtualization" thing was the worst design decision by microsoft, ever.
so maybe the system has this policy enabled and that's why virtualization doesn't work for you?
--
so probably the ultimate checklist would be:
is the application x86 or x64?
does the exe have a manifest (including the requestedExecutionLevel)?
have you checked the read-only attribute (e.g. of those INI files)?
is there a policy to force the EnableVirtualization to 0?
have you tried the AppCompatFlags with RUNASIVOKER?
or simply go for ACL instead of virtualization
--
in the end we are discussing how to get on old legacy application to run.
by using whatever workarounds and hacks we can think of.
this should probably better discussed on either superuser or serverfault.
at stackoverflow (targeted for programmers) we all know: it's about time to get all of our own programs compatible with UAC concept and how to implement things the "right" way - the "microsoft" way :)
Is it possible to run handle.exe (from sysinternals) from a service (in windows7) without having to turn off UAC?
The service is a custom c-app that needs to find out which process is locking a file it tries to access and handle.exe seems to be a good way to solve it but i can't get it to work with UAC turned on. This app runs all the time so i can't have a UAC prompt while its running but its fine if it shows up at startup.
Handle.exe works fine from an admin commandprompt but fails when trying to run from a normal prompt.
I call handle.exe from CreateProcess() and get the output from pipes. I guess there should be a way to solve this but i can't figure it out. Setting up the service to log in from an admin account does not seem to work.
UAC does not affect services (it only affects interactive sessions) so that should work.
However, if you don't want to move your entire program into a service then there are better ways to do this which don't require creating, installing and managing a separate service process in addition to your main program.
If your program requires admin rights to work at all, and this isn't the only place it will require them, then you could flag your program (via its embedded manifest resource) as requiring administrator rights. It will then trigger one UAC prompt whenever it is run and be run with full admin rights, including the ability to run Handle.exe.
On the other hand, if this is the only place where your program needs admin rights, it may make sense to create a COM DLL which wraps your Handle.exe call (or any other admin work) so that you can use UAC to make elevated calls to that function from your non-elevated app. You will then trigger a UAC prompt each time you create (an elevated version of) that COM object. You can keep the COM object open as long as you want, and create it whenever you want, so when and how often the UAC prompt(s) appear are still up to you.
Both 1 & 2 are standard uses of UAC so any good documentation or tutorial on UAC will describe how to do them in detail.
You may want to look at the Win32 API method CreateProcessWithLogonW.
There is also an elevate VBS script here you may learn from: http://technet.microsoft.com/en-us/magazine/2007.06.utilityspotlight.aspx
I need to write a C program that will allow me to read/write files that are owned by root. However, I can only run the code under another user. I have the root password, but there are no "sudo" or "su" commands on the system, so I have no way of accessing the root account (there are practically no shell commands whatsoever, actually). I don't know a whole lot about UNIX permissions, so I don't know whether or not it is actually possible to do this without exploiting the system in some way or running a program owned by root itself (with +s or whatever). Any advice?
Thanks!
P.S. No, this isn't anything malicious, this is on an iPhone.
Under the UNIX permissions system, you need to run a file owned by root itself that's marked setuid-root (+s, as you said) or communicate with some process that is already running as root.
If there is no such file, you are out of luck.
You can do this with setting suid bit to application, but if you want from this c application run a some shell this was be runned on local user if you do it normally this is security system.
However you can read/write/execute files owned by root, but if your user is not in group of file your target file must have setted read/write/execute on last 3 bits or when your user is in file owner group you must check/apply this to 3 bits in middle position. (3 first bits setting permission to owner but this may not by a usable information for you).
If you dont have any access to root account. Then if group and other user permissions dont access functions as you must have, you can't do with this anything except trying get some prilveaged user for access this file. In other cases you can do some fixes in file access permissions but not from this system, you must get hard drive from this device and attach to other to change it or load on this device some live system to change this. However you can do this on privleaged system not on this.
More information about SUID bits you can find at:
http://www.codecoffee.com/tipsforlinux/articles/028.html
http://www.everyjoe.com/newlinuxuser/explain-what-is-setuid-and-setgid/
The iPhone SDK doesn't allow this. Your application is sandboxed and it is not allowed to go outside of that sandbox except in very specific ways provided by Apple. The only way to do this on an iPhone is to jailbreak it.