Re: Manifests and requestedExecutionLevel
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:gan893dl11esbs8ud66juus1e3kaitoiae@4ax.com...
I had already proposed this to the customer (last week) and it was
apparently rejected. I
had used a two-process scheme some years ago which worked very well. I
had asked if named
pipes would solve the problem, and did not get a positive response. So
I'm stuck with the
current single-executable model. The existing app is a single executable,
and runs on
various other versions of Windows, so I think this is not an option
they'll entertain.
It sounds like if you can originally start your process with Medium MIC,
then you would be happy for the most part. So why don't you create a small
..exe which simply starts your main .exe with Medium MIC (using the
CodeProject UAC elevator techniques)?
Now once your process is running with Medium MIC, then it asks user to
select "target app", and if in the rare case this target app is running at
High MIC, then you need to shutdown your process and restart it at High MIC.
Since you already have the small .exe running (see above), which can wait
for your main app to quit using WaitForSingleObject(), you can return an
error code saying it needs to be restarted at High MIC and exit, then your
small .exe wakes up and restarts your main app with High MIC (again using
CodeProject UAC elevator techniques).
Since this approach essentially keeps your main exe the same (the code to
find the target app and the code that then does something with it is still
kept in the same exe), your customer might go for it. Because on the
down-level Windows, the small .exe can be ignored and only the main exe
used, same as it always was.
FWIW, when people talk about standard user priviledge, that is Medium MIC.
And Admin user priviledge is High MIC. This is from Kenny Kerr article.
http://weblogs.asp.net/kennykerr/archive/2006/09/29/Windows-Vista-for-Developers-_1320_-Part-4-_1320_-User-Account-Control.aspx
****
This explains integrity levels as if they are an orthogonal concept to
ACL-related
privileges. The code from this article has proven to be very useful, and
forms the core
of most of what I've done. I've also used this article as the basis for
my Token Explorer
program, which I'm working on in parallel. It seems to indicate that
integrity level is
still independent.
Yes, I think the problem here is both you and I struggle with ACL concepts,
and then there is this new MIC thing which UAC is based on. Here is my
concept of MIC. Kenny seems to be clear that UAC is in addition to ACL and
is a simpler concept. It compares an exe's MIC with the MIC of the
resources it desires to interact with, and if it is less, it can't access
the resource. Examples of resources which have MIC's are other exe's (to
determine if you can send them messages, hook them, etc.), folders (to
determine if your executable can write into c:\, for example), etc.
There are 4 levels of MIC, and only the middle 2 are accessible by us.
Those are High and Medium.
High == "run as administrator" == "elevated"
Medium == "run as standard user" == "non-elevated"
By default, an .exe's MIC is the same as the process which started it, e.g.
as if the manifest had:
<v3:requestedExecutionLevel level="asInvoker" />
The manifest has the capability of telling Vista that it needs to be started
with High MIC:
<v3:requestedExecutionLevel level="requireAdministrator" />
What is missing is the capability of telling Vista that it needs to be
started with Medium MIC. This was clearly spelled out in the CodeProject
Vista Elevator article, where he went through great pains to start the app
with Medium MIC (non-elevated). The first attempt used the Windows
scheduler (which runs at Medium MIC), but this has problems for Installer
apps that, because they are elevated, run in the Admin account, and there
the Windows scheduler runs at High MIC, so any process it starts is also run
at High MIC. His second attempt is available from his website (not
CodeProject), and I haven't looked there to see how he worked around this.
Anyway, I could be wrong, but I don't think you need to be concerned about
ACL's. It gets confusing because ACL's are used when you talk about "Admin
priviledges", and now High MIC is also called "Run as Admin". But they are
not the same, since even a user account with Admin priviledges normally
starts processes with Medium MIC (and not High MIC or "Run as admin").
Kenny Kerr's article explains all this much better than I just did, but
maybe this explanation gives the essence that then makes Kerr's article
understandable.
I had first assumed that because I was running VS as an admin (the
recommended practice) that my debugged process was of course running as
admin, so I went
outside VS and launched the exe from the normal (non-elevated) shell, and
it *still*
seemed to come up with Integrity Level High, making it unable to
communicate as desired.
What do you mean, "seemed to" come up with Integrity level High? Did you
check using Process Explorer (as described in the Kenny Kerr article) that
it was running at High MIC even when launched from Explorer? If it is
running at High MIC (btw. MIC == "Integrity Level") then either it has a
manifest with the
<v3:requestedPrivileges>
<!-- level can be "asInvoker", "highestAvailable", or
"requireAdministrator" -->
<v3:requestedExecutionLevel level="requireAdministrator" />
</v3:requestedPrivileges>
or Explorer (the Invoker) is itself elevated. Again, check with Process
Explorer.
In addition, unless you are using an external .manifest file, your app's
manifest is in the .exe. Open the .exe within Visual Studio and check it's
resources and see what is in the manifest.
Good luck,
David