Re: Manifests and requestedExecutionLevel
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Wed, 11 Jul 2007 00:43:30 -0400
See below...
On Tue, 10 Jul 2007 17:13:03 -0700, "David Ching" <dc@xxxxxxxxxxxxxxxxxxxxxx> wrote:
****
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:n1q793po9glnpmvos8kbrflaorrmevvqmj@xxxxxxxxxx
Actually, I don't need administrative rights; as far as I can tell, I'm
running as a
limited user. It's the integrity level, which I have to *reduce*, that is
giving me
problems. Or is the integrity level what is being addressed by
"administrative rights"?
It isn't clear, because it looks like two independent people are writing
about this stuff.
If integrity level is directly correlated with the rights, then why are
such meaningless
phrases as "asInvoker", "asAdministrator", etc. being used to describe
what the API thinks
of as UIPI Low, Medium, and High? Is "asAdministrator" ==
"SECURITY_MANDATORY_HIGH_RID"?
Or not? It is not at all clear. Since I am not running as an
administrator, I do not
want to see anything as "high". But I find that if I simply run my
program from the
shell, as a limited user (as opposed to under VS, which *is* running as
administrator)
then I *still* come up running as "High". So these levels apparently do
*not* correlate
with concepts like "running as administrator".
If I can raise rights, why can't I specify that an app should run with
*reduced* rights?
The problem is that I am currently running "High", so I can post messages
to the "Medium"
app, but it can't post back to me. But finding the app cannot be done in
InitInstance for
a variety of technical reasons, some of which I'm not at liberty to
explain (NDA and all
that)--it requires user interaction. But once the user has designated the
chosen target
app, an action that takes some effort, I have to relaunch if I discover
that my rights are
not == the rights of the app. Note that they *must* be ==, so running as
"administrator"
isn't right unless the target app is already at that level (again, I can't
discuss the
real details) and it is unlike the target app will be at that level.
It's a real pain to debug, because after I launch under VS, then relaunch,
I have to go
back to VS and attach to the new process. If VS had a way to specify the
integrity level
for launch, this would solve much of my current problem, although not the
long-term
deployment problem.
Dude, it's not that hard. Clearly if you need to send/post messages between
the two apps, then they must be running at the same MIC (Low, Medium, High,
System). What I suggest is you break your program into two .exe's. The
first one runs at the default MIC (or High, if necessary) and the user then
selects the target app somehow. Then this first one uses
CreateProcessAsUser to launch the second .exe with the MIC of the target one
(using the techniques described at
http://www.codeproject.com/vista-security/VistaElevator.asp).
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.
*****
****
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. 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.
joe
*****
Joseph M. Newcomer [MVP]
-- David
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Follow-Ups:
- Re: Manifests and requestedExecutionLevel
- From: David Ching
- Re: Manifests and requestedExecutionLevel
- References:
- Manifests and requestedExecutionLevel
- From: Joseph M . Newcomer
- Re: Manifests and requestedExecutionLevel
- From: David Ching
- Re: Manifests and requestedExecutionLevel
- From: Joseph M . Newcomer
- Re: Manifests and requestedExecutionLevel
- From: David Ching
- Re: Manifests and requestedExecutionLevel
- From: Joseph M . Newcomer
- Re: Manifests and requestedExecutionLevel
- From: David Ching
- Re: Manifests and requestedExecutionLevel
- From: David Ching
- Manifests and requestedExecutionLevel
- Prev by Date: Re: Forcing a thread to use a specific processor?
- Next by Date: Re: Configuration type identifier
- Previous by thread: Re: Manifests and requestedExecutionLevel
- Next by thread: Re: Manifests and requestedExecutionLevel
- Index(es):
Relevant Pages
|
Loading