Re: Manifests and requestedExecutionLevel

Tech-Archive recommends: Fix windows errors by optimizing your registry

That is what I've had to do, since 99% of the time the co-process will be running as
Medium. It has been running for several days that way. But this violates some issues
about simplicity of installation and use that the customer finds desirable criteria. So
the preference was to launch it as Medium, and if the user selects a target window which
is High, restarting it, reloading the list of windows, re-selecting the previous
selection, resetting the selected options,setting the focus to whatever control the user
had been focused on, and then communicating with the target process. I'm trying to avoid
the complexities of state maintenance. The code for the state maintenance is complex, and
there is still negotiation about what should happen if a 'high' window is selected.

We've been down several design paths, and all the obvious ones (such as the one you
suggest, which is the one which has been running since last week) are producing concerns
about whether or not they are acceptable. Most of these problems would go away if there
were a simple way to launch at Medium MIC and be done with it. There is even a suggestion
that talking to a High MIC process would simply be forbidden, so I was tasked with
investigating ways to cause this launch to occur at the correct level in the first place,
without using the current intermediate launch mechanism (which, as I said, is a real pain
to debug with). And that's where the frustration has come in: there's enough missing
information to make it difficult to determine if the lack of information is due to lack of
functionality, inadequate documention, or whatver. For example, although I find that for
an actual 64-bit build the processorarchitecture="amd64", the documentation CLEARLY states
the ONLY two allowable values are "x86" and "ia64". Given how long the AMD64 has been out
and running Windows, do you think I give much credibility to documentation that has
clearly not been updated in 3 or 4 years? Could I tell from reading the documentation
that the statement "The only allowable value is win32" has any meaning in a win64
environment? (It turns out that inspection of a win64 manifest shows that it really does
say "win32", even though this makes no sense). So the documentation is misleading,
confusing, and certainly out of touch with reality. For all I know there have been
massive changes in what manifests do, and there is no real source of authoritative
information.

Because of the need to restore state transparently, the executable cannot remain the same,
which is a situation we are trying to avoid.
joe
On Wed, 11 Jul 2007 11:54:24 GMT, "David Ching" <dc@xxxxxxxxxxxxxxxxxxxxxx> wrote:

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:gan893dl11esbs8ud66juus1e3kaitoiae@xxxxxxxxxx
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

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Manifests and requestedExecutionLevel
    ... launching a second .exe at Medium MIC. ... without using the current intermediate launch mechanism (which, as I said, ... do you think I give much credibility to documentation ...
    (microsoft.public.vc.mfc)
  • Re: Manifests and requestedExecutionLevel
    ... The existing app is a single executable, ... Since you already have the small .exe running, ... And Admin user priviledge is High MIC. ... The manifest has the capability of telling Vista that it needs to be started ...
    (microsoft.public.vc.mfc)
  • Re: C# Newby Web App - Browser Question
    ... most installs have it set to Medium. ... good amount of alignment work that you might have put into your app. ... their browser displays everything REALLY large. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Howto evaluate if current user is of administrators group?
    ... In terms of having an app that both admin and non-admin users can do stuff with, I haven't don't much in that line, however, my understanding is that apps are either running with an admin token or not, and there isn't a way to "add one" later. ... It confirms that you have to run an exe separately to have admin privs, however, you can use CreateProcess to run an app with admin rights, so you could theoretically keep it all in 1 exe and re-run it if you need to elevate. ... again you say someting like "just manifest your application to require xxx privileges". ...
    (microsoft.public.development.device.drivers)
  • Re: To anyone complaining that their bug wasnt fixed...
    ... Because if you write any type of medium to large app you don't just switch ... compilers just because a new one comes out. ...
    (borland.public.delphi.non-technical)