Windows 7 uses an automatic mechanism to detect whether an application needs elevated administrator privileges. Or the application itself has a manifest.
Is there a way to find out programmatically whether a specified application needs elevated administrator privileges or not?
I don't want to start it to find it out.
Thank you ;).
There's really just one way to tell Windows that a program needs to be elevated and that's through the manifest file. Manifest files can either be embedded within an assembly (exe/dll) or can live in a separate file named <YOUR_APP>.exe.manifest. That's really the only way and probably the only way that you can safely check. Officially.
Windows also contains a giant database that's used for application compatibility. If Microsoft has tested an app and found that it breaks when an OS upgrade happens they sometimes creates an entry in the database to essentially hack the app. Sometimes they lie about the current OS version, sometimes they automatically run as administrator, sometimes they do a bunch of other things. You can view the database using the Application Compatibility Toolkit. I don't know if there's an official way to query the database via code. This blog post talks about a tool that the blogger made but apparently never release.
The last automatic elevation mechanism is algorithm that tries to determine if that app is an installer. According to MSDN these attributes are checked:
Filename includes keywords like "install," "setup," "update," etc.
Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename,
Internal Name, and Export Name.
Keywords in the side-by-side manifest embedded in the executable.
Keywords in specific StringTable entries linked in the executable.
Key attributes in the RC data linked in the executable.
Targeted sequences of bytes within the executable.
The keywords and sequences of bytes were derived from common
characteristics observed from various installer technologies.
Lastly, an app can run as a normal user but spawn a child process that requires elevated privileges. I don't know if there's really any way to actually detect that short of decompiling the app itself.
Related
How Can a Web Page Display What Version a File is In Program Files Directory?
For example, if I wanted to send a user a URL that would show the user what version of our software is installed (version number and release date) on their Windows PC. I'm just talking about file properties, not actually running something.
Is there a way to do this with .Net/ASP.Net?
The answer is no.
The best you can do with HTML5 or Javascript is to let the user select a file and even then you have very limited access to properties (at most name, size and type) without having the user upload the file.
The most efficient solution right now would be to serve a very basic clickonce application which would locate the files, read the properties and send the information back to the server. From there you can choose to redirect the user back to your website with the information you collected.
Generally access to the Programm folder is limited at best. There used to be a time when we even would write data like Configuration files there. That was Windows 95/98. And it was frowned upon back then.
With the introduction of NTFS with Windows NT (and later XP in the Consumer area), enforceable rules were put in place. Rights tend to be highly limited. This is even more true of Webservers, as they tend to be prime targets for hacking. The only rights you can expected a Webserver to have is read rights to it's programm and the content directory. Maybe if the admin is really nice and it really helps with performance, it might have write rights on a Temporary subfolder of Contents.
Reading out your version from a file is propably possible with only read rights, but not the right way. Usually you just let the compiler hardcode (insert as constant) whatever Version is given in the Project file or by the Version Tracking Software.
So the first thing is that you need some approach of Version Control. And then your answer depends "however this Version control mechanism does tracking of the Compiled version". There is some limited version tracking support in Visual Studio itself. But there is also full, 3rd party Version tracking Software.
I have used Flexera's Installshield and it has seemed to work for the most part except the shortcuts it placed in the start menu and on the desktop.
The issue arises when the program starts and returns an error with opening the sqlite database file.
The issue is fixed by running the actual .exe from the program files folder, and if I create a manual shortcut.
I have noticed that the automatic shortcuts they have a target of what the manual shortcut has for a target location.
Any ideas?
I am not in a position to propose a direct solution for your specific problem. On the other hand, I have had some paths/relative-reference problems in the past when working with different Windows installer packages which I solved by running a program passing all the required information to the installer.
Example of what I mean:
A small program is executed right before starting the installation. It retrieves all the required information (e.g., desktop's path) and writes it to a temporary location (e.g., Windows Registry).
The main installation package is started, reads/deletes the
information from the temporary location and brings it into account
while performing the installation (e.g., path for the shortcuts).
Depending upon the available setup options, you might perform the aforementioned actions in different ways. The simplest alternative I see is: creating an .exe file (install.exe), only one to be executed by the user; it will be in charge of retrieving all the required information, writing it to the temporary location and calling the main package (\installation files\setup.msi). Right after being started, the installation package will read the information from the corresponding temporary locations, delete them and bring this information into account while performing the corresponding actions (setting up the shortcuts).
The main reason why I prefer to rely on this kind of configurations (preliminary .exe calling the main package or script/.exe being called by the installation package as the first action) is because it offers a high flexibility. It does not only accont for eventual problems/incompatibilities from the installation software, but also sets up a framework allowing me to perform more complex actions (e.g., security system) whose implemention is much easier by relying on the corresponding programming language (C# in this case).
I want to track a setting system-wide on the target machine- it is a run time counter that keeps track of how many times my client runs my software. I decided to put this value in the registry, but I really want to track how many times it is run for the whole system, not just for the current user account.
I would expect to use HKLM to track this at a machine level, but UAC doesn't like this nowdays.
Is there a correct way to read and write a setting that is machine-wide?
HKLM isn't for this type of use (since Windows XP at least).
Use the %PROGRAMDATA% folder instead (which you can also get via the WinAPI function SHGetKnownFolderPath with FOLDERID_ProgramData (SHGetFolderPath with CSIDL_APPDATA on Windows versions prior to Vista). It's specifically designed for application data that is global to all users of the machine. (On Windows 7, this is the C:\ProgramData folder by default.) Your application should create a directory beneath there and store the counter information in a file in that location instead.
(It also means you don't have to defeat the purpose of UAC by allowing public write access to the registry in inappropriate locations.)
From Environment.SpecialFolder Enumeration:
CommonApplicationData The directory that serves as a common repository for application-specific data that is used by all users.
Have a "CommonApplicationData\Your Company Name\Your Product Name" folder created in your setup program and change the ACL for the folder to allow limited user full control permissions (the inherited permission is read only for limited users). You can do this via the LockPermissions MSI table, or if your setup program does not support LockPermissions, create a custom action to change the ACL.
You also need to handle potential edit conflicts created by fast user switching.
When we create a SetUp & Deployment project for our application in .net, the default folder for our application to be installed is being set as C:\Program Files.....
Our application will run perfectly if we are using a Windows XP machine. But if we are using a Windows Vista or Windows 7 machine, the application wont run perfectly, especially if we are performing any file operations in our application...
Can anyone find a solution for this problem? Is there any means to penetrate this User Account Control and File Access Controls of Windows 7? or can any1 give a choice to change the default installation folder from [ProgramFilesFolder]\[Manufacturer]\[ProductName] to some other folder?
If your application writes to any files under its install folder (i.e. under Program Files if default path is used), then it is badly written. You shouldn't try to circumvent OS security mechanisms to protect the user from badly written apps; you should rather fix your app so that it works correctly.
And it is, of course, not a .NET issue at all. Any application doing the same thing, no matter which language/framework it's written in, will have the same problem.
You should still install your application in Program Files folder. there are good reasons to have it there - a single copy for all users, in a well known locked place where nobody but an admin can tamper with your binaries.
However, any file operation you are doing should be in one of the standard Windows locations for user-writable files. There are several such folders, depending on the file usage model. You can read more about these in the following SO questions :
My winform app uses xml files to store data, where should I store them so Vista users can write to them?
Vista and ProgramData
Data shared among all users should go in C:\ProgramData (use Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) to find out where it actually lives -- it can be different between Windows versions).
Data specific to the user should be in SpecialFolder.ApplicationData. If the user has a roaming profile, this is shared between machines.
Data specific to the user that's also specific to the machine should be in SpecialFolder.LocalApplicationData.
If you really need to put something in your program's installation directory, you need to do this with Administrator privileges.
You should either do this by prompting for elevation the first time that the program is run. Preferably, you should do this during installation (because you're already elevated).
First of all, you should not set your app to install under C:\Program Files\..., you should instead set it to %PROGRAMFILES%\... While these will usually equate to the same thing, they can be different on a 64 bit system, or they can be wildly different if the system has been set that way.
As already mentioned, don't try to circumvent the UAC, it is there for a reason, and your program is no more special than any other program on the system. Instead what you should do is set your app manifest to demand administrative level permission upon launch (which if granted bypasses the file system virtualization, although the user can decline it or possibly not even have the rights to launch something as admin). The other thing you can do is set the ACLs on the folder that your app sits in, and give all users on the machine read/write access to that folder (this would have to be done at install time).
Or you can do things the proper way and store your data files in the %APPDATA% folder, which you have full rights to, although these folders are specific to each individual user of the system.
I'd suggest start here http://channel9.msdn.com/pdc2008/PC51/
That will give you a good foundation.
I have task to give in my application possibility to open document that is located on server, but I dont know at all how to implement this.
Please give the main idea how can i do this?
If you are trying to open a file based on it's MIME extension and not prompt the user, you really can't do that in a Silverlight web application (for either case, MIME launching or opening a file without prompting the user). Silverlight isn't a "browser standard", and a lot of it's seemingly crippled features are done so out of the name of security, and a safer user experience. (You don't want a Silverlight app randomly reading files on your hard drive without you knowing about it and silently uploading them somewhere now, do you?)
I believe you can do whatever it is you're trying to do in Silverlight 4, but it requires elevated permissions (and consequently that it must be installed out of browser), and a little bit of COM hackery.
The elevated permissions do not give you direct access to files outside of the "My" Folders, so I don't think you are going to be able to do what you want if you want to preserve cross platform compatibility to the Mac.
However, if you don't care about that, you can do just about anything you want regarding file access by utilizing the Windows system COM objects (specifically the WScript.Shell and Scripting.FileSystemObject objects).
Here's and example.
Scroll to the section of COM Interoperability.