> "Jimmy Brush" <email@example.com> wrote
>>> I sure was wrong on that. I was going from memory. Went back into
>>> the standard user account and sure enough regedit ran without
>>> requesting elevation. Sorry to the OP.
>> You wouldn't think whether the system shows a prompt or not would be
>> so difficult, but the rules are actually fairly complex.
> Yep, still haven't figured out all aspects of this. I'm guessing
> regedit is allowed in a standard user account but one can only edit user
> settings. When invoking regedit from an admin account it is assumed you
> would want access to all settings hence the need for elevation?
No matter what, programs running in an account can only use at most
whatever privileges the user is assigned, unless the program is started
inside of another user account (i.e. elevating from a standard user
account requires username and password from an admin).
An application can specify that it will not run unless it's started by
an administrator (requireAdministrator). This will cause the application
to prompt for consent when run by an admin, and prompt for credentials
when not run by an admin. In either case, it must be ran by an
administrator; it simply cannot be ran by a standard user, and if it
somehow did run, it would fail to function properly, because the user
doesn't have the rights.
If the app doesn't require an administrator to run it, then it can say
that it wants to use however much privilege the user has
(highestAvailable). If the user is admin, then the program prompts for
consent (since it will be assigned admin power in this case). However,
if the user is not an admin, then no prompt is issued, but the
application is given whatever privileges the user is assigned (it ALWAYS
runs with the actual user's token). This is the mode that regedit runs in.
Finally, the app can say that it never needs any extra privileges,
regardless of what privileges the user is assigned (asInvoker). In this
case, the app always runs as if a standard user started it (it ALWAYS
runs with a filtered token), and never prompts. This is the mode
explorer runs it.
Note that it is almost always the application itself that determines at
what privilege level it runs at, and thus its own prompting behavior.
However, this is made more complex by the "installer detection" and app
compat features of Vista, where MS may have pre-detected what privilege
level a legacy app needs, and it is not immediately obvious to the user
how to control this behavior.
These 3 different privilege states make a lot of sense when considering
plain-ol' admin and standard user accounts, but things get really
interesting when you are using an account that is not an admin account,
but has extra privileges (like the old power users group).
In that case, you will not be able to run programs that require
administrator (unless u enter an admin password). And, the only programs
that will be able to actually use your extra power will be ones that ask
for highestAvailable (like regedit). A program that specifies that it
never needs any extra privilege (like explorer) will not be able to use
the extra privilege.
This can lead to some interesting problems, but in general it works out
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/