using UAC permissions in a program

  • Thread starter Thread starter Michael Harvey
  • Start date Start date
M

Michael Harvey

Hi, my program doesn't seem to be recognizing UAC permissions.

The following program opens a file in the program files directory for read
write access. User account controls is turned on. This program succeeds in
opening the file for writing, although the program files directory is
supposed to be write protected. How do I make this program deny writing to
the file when UAC is turned on?


#include "stdafx.h"
#include <windef.h>
int _tmain(int argc, _TCHAR* argv[])
{
OFSTRUCT OpenBuff;
HFILE hf;
if (HFILE_ERROR == (hf = OpenFile("C:\\program files\\xyz\\abc.cfg",
&OpenBuff, OF_READWRITE)))
printf ("\nError opening config file.");
else {
printf ("\nSuccess opening config file.");
_lclose (hf);
}
getchar ();
return 0;
}
 
Hello,

Your application must include a Vista-style manifest - this will inform
Windows that your application is designed for Windows Vista, and will turn
off any "compatability hacks" that it uses to make legacy applications work.

Here's some resources to help:

The Windows Vista Developer Story: Windows Vista Application Development
Requirements for User Account Control
http://msdn2.microsoft.com/en-us/library/aa905330.aspx

Designing Applications for Windows Vista
http://download.microsoft.com/download/d/9/b/d9beb875-bc1d-4338-a655-251f4f353b2e/top10wave.exe


--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/
 
Hi, my program doesn't seem to be recognizing UAC permissions.
The following program opens a file in the program files directory for read
write access. User account controls is turned on. This program succeeds in
opening the file for writing, although the program files directory is
supposed to be write protected. How do I make this program deny writing to
the file when UAC is turned on?
Click to expand...

Jimmy is correct, but you also need to specify in the manifest that you do
not want your program to get virtualized. Look in Program Files. That's not
where the file you opened went. Look in C:\Users\<your
username>\AppData\Local\VirtualStore\Program Files. That's where the file
went.

If you specify the requestedExecutionLevel in the manifest, virtualization
gets turned off.
 
Jesper said:
Jimmy is correct, but you also need to specify in the manifest that you do
not want your program to get virtualized. Look in Program Files. That's
not
where the file you opened went. Look in C:\Users\<your
username>\AppData\Local\VirtualStore\Program Files. That's where the file
went.

If you specify the requestedExecutionLevel in the manifest, virtualization
gets turned off.
Click to expand...

Thanks. Suppose I don't want to bother with a manifest and I want writes to
be seen by all other users. Where else could I put the file?
 
%AllUsersProfile% if it is static settings

If it needs to be writeable by all users you need to modify the permissions
 
I'm a little concerned about using the "Public" directory as the name gives
the impression of being unsecure.

Could I access a directory like C:\MyAppData for read/write without
modifying permissions? I notice when I create the directory it gives the
necessary permissions to "Authenticated Users", but not to "Users". How
would a user by authenticated?
 
I'm a little concerned about using the "Public" directory as the name gives
the impression of being unsecure.
Click to expand...

Data that is read-write for multiple users IS insecure. That's pretty much
the definition of it.
Could I access a directory like C:\MyAppData for read/write without
modifying permissions? I notice when I create the directory it gives the
necessary permissions to "Authenticated Users", but not to "Users". How
would a user by authenticated?
Click to expand...

The functional difference between Authenticated Users and Users is that
Guests are members of Users, but not Authenticated Users. As there are no
enabled Guest accounts on most systems that means that for all practical
purposes they are identical.

You should not pollute the root of the file system with application specific
data. If it is configuration data, it goes in %AllUsersProfile%. If it is
application data, it should go in either %public% (if you want users to see
it outside the program) or %AllUsersProfile% if you do not. If you put it in
the latter you will need to programmatically set an ACL on it to ensure that
the intended users get the right set of permissions.
 
Back
Top