Right, let's explain UAC.
When a member of the Administrators group logs in to Windows with UAC
enabled, he gets a token which does not contain the Administrators group
(well, actually it does, for Deny Only - that is, the Administrators group
cannot be used to gain access, but if an ACL explicitly Denies
administrators access, that will apply). Also, the privileges assigned only
to the Administrators group are not present.
The token is an object which represents a cached copy of the user's account,
session, groups that he's a member of (including groups which contain other
groups he's a member of, recursively), and privileges that the user has.
When making security decisions against an access control list, the system
checks the groups and associated flags in the user's token, and in some
cases sees if a privilege is enabled (for example, if the user tries to take
ownership of an object, the ACL is first checked to see if they have
permission to do so, then if not the system checks to see if they have the
Take Ownership privilege).
When you run a program from Explorer, it checks to see if there's a Vista
manifest present, which includes the requestedExecutionLevel element. If so,
depending on what's in there and the system security settings, you may get a
prompt. The default settings are:
* asInvoker - no prompt, program runs using login token
* requireAdministrator - always prompt, Windows adds Administrators
group and privileges to token for program
* highestAvailable - if user is a member of Administrators, as
requireAdministrator, otherwise as asInvoker.
If not an administrator, the prompt is instead for an account and password
which is an administrator. The program then runs as that user.
For legacy programs without a manifest, Windows has some heuristics to
detect programs that might require elevation. The most well-known is the
setup program heuristic, which basically says that if the word 'setup' or
'install' is part of the program's name or in the string resources, it's a
legacy setup program and it'll need elevation. Windows also has a
compatibility database that can apply an elevation requirement for known
programs that need it (VB 6.0 has one - SP4 didn't crash as standard user on
XP but SP5 and SP6 do). As an additional mitigation, the redirection
behaviour you've discovered is applied. This redirects writes to a limited
number of locations; once a redirected file or key is present, reads will
happen to that file or key rather than the protected locations. To turn off
redirection, add a manifest. Again, the shim database turns off redirection
for some known good programs.
Explorer will prompt you for permission if you're trying to do something
counter to the ACL and you're a member of the Administrators group. When
you're trying to create the folder, you're doing it in a protected location.
Do it somewhere else.
When you do this, Explorer just keeps the privilege for long enough to do
the immediate task. When you create a new folder by right-clicking and
selecting New, Folder, Windows actually creates a directory named New
Folder. When you enter a new name, it then needs to rename the directory and
so Explorer asks you for permission again to rename it. Yes, this does suck
and I hope it can be worked around.
The boundary for UAC operations is starting a new process. Any operations
that produce a prompt that don't initially seem to be starting a process
(e.g. Explorer above) are actually doing it in the background. Once a
program is running all security decisions are made in the context of the
token assigned, so a Notepad started elevated can indeed edit some files
that a non-elevated Notepad cannot.
If you're having problems with UAC, you've been doing it wrong for years. Go
back and run as a standard user on Windows XP, then fix all the bugs with
that.
Now, to your specific problems:
- If the user-modifiable data under Program Files is per-user, it
should be moved to somewhere under the user's profile. You can find
appropriate folders with SHGetFolderPath. If the data needs to roam with the
user's roaming profile (which most should, but not if it's very large), it
goes in CSIDL_APPDATA. If it's tied to the system somehow (e.g. paths), it
goes in CSIDL_LOCAL_APPDATA. If it's common to all users it goes in
CSIDL_COMMON_APPDATA.
- It's certainly possible to get performance information without
having elevated privileges. I'm running Process Explorer non-elevated right
now, and it's showing process CPU usage. I don't know what APIs you're
using, and I don't know what APIs Process Explorer is using either, but I
would expect the Performance Data Helper APIs to work. Process Explorer
doesn't use that, but then it has the requirement not to be dependent on any
non-system-supplied library even on NT 4.0. Presumably it's using the raw
registry interface, which PDH is a wrapper on top of.
I'm also concerned that average users will not understand why UAC is
stopping them doing whatever they want (as demonstrated, developers don't),
but it's a stretch to say that everyone will turn UAC off (I haven't, but
then I ran as a standard user on XP through choice). Working properly for
non-admin users has been in the Logo requirements since before Windows 2000.
It's about time we started getting it right.
--
Mike Dimmick
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer
Sent: 07 January 2008 14:45
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to detect if UAC is turned on
On Jan 4, 2008 6:04 PM, Chesong Lee <[EMAIL PROTECTED]> wrote:
Can I ask why you want to prevent your setup to be launched with UAC
enabled?
Your installer will be run with UAC on most of the cases.
Probably not without degrading the thread to a flame fest :-)
Let's just say after careful evaluation we've determined that UAC is another
monumental failure in the context of Microsoft security. Since so little in
the system actually works with it enabled, including simple things like
loading a text file into notepad.exe, which will fail silently in some
contexts but not others (for the same file) when UAC is enabled, and the
effect of UAC is simply to train users to click "allow" for everything
because it is required for nearly everything, sometimes requiring three
confirmation dialogs for a trivial operation like creating a folder (the
Apple commercial didn't go far enough) it effectively makes any meaningful
warnings get lost in the noise. The very users it is meant to protect are
exactly the ones who will simply learn to implicitly "trust" everything
instead. I'm not aware of any computer-literate user that doesn't turn off
UAC immediately.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
