Re: How to work around UAC?
- From: "Chris Becke" <chris.becke@xxxxxxxxx>
- Date: Mon, 15 Oct 2007 14:06:02 +0200
Search for WindowsVistaUACDevReqs.doc
You should get a download page following this link:
http://www.microsoft.com/downloads/details.aspx?familyid=ba73b169-a648-49af-bc5e-a2eebb74c16b&displaylang=en
To summarize:
Yoiu are going to need to manifest all *your* apps as this will prevent
virtualization, and it will properly cause "Administrator" prompts to appear
for any apps that need to write to system locations.
Legacy apps that dont use manifests will be able to read data in the common
system locations, but might virtualize if they attempt to write.
To bypass this, either ensure that the legacy apps get updaed with manifests
(you *CAN* just drop a appname.exe.manifest into directory containing a
legacy app to disable virtualization in that app.)
Once an app has virtualization disabled, it will get access denied errors
trying to access protected resouces in inappropriate ways (Rather than being
virtualized) so you need to consider getting your installer to modify the
ACL for the registry keys and folders containing stuff that needs to be
writiable by non administrator mode components.
"Mick" <Mick@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C780262B-3ABD-4102-9A20-25267857F8C2@xxxxxxxxxxxxxxxx
We are having lots of problems with UAC.
Our product consists of several NT services that run under the SYSTEM
account, as well as several DLLs, and a couple of regular Windows apps.
The
DLLs are loaded by our services, and by many end-user applications.
Several
of our DLLs and applications need to be able to exchange data using
various
IPC mechanisms, such as named pipes or shared memory blocks. For instance,
one of our DLLs is an LSP that is loaded for all applications that use
socket
communications. The system loads our LSP whenever a Windows socket
application starts up. The LSP reads its configuration parameters from the
registry, and then it opens named pipes to one or more of our services.
Since
the LSP is not specific to a single user, we store its data under
HKEY_LOCAL_MACHINE. This doesn't work in Vista.
Our product works fine on Win2K and XP, but when we try to run it on a
Vista
system, nothing works! From our initial debugging, it appears that UAC is
the
root of all our problems. Nothing works with UAC turned on. We cannot
access
any of our registry keys, can't create or open named pipes, mutexes,
shared
memory blocks, or any other sharable objects. We can't even create a
simple
text file! Our code uses null DACLs for most objects, which should allow
access to anyone, but when UAC is on, nothing works. If we turn UAC off,
most
of the problems go away. Unfortunately, we can't simply ask our customers
to
turn off UAC.
Where are non user-specific services supposed to store their registry
information, if not in HKEY_LOCAL_MACHINE?
Do DACLs work differently under Vista? If so, what are the differences and
where are they documented?
I understand that we can use manifest files to bypass virtualization for
our
own applications, but how can we get around it for our DLLs that link to
other applications?
What about file system virtualization? Our debug trace logging can't even
create a simple text file, even when the user created the folder! Where is
all this stuff documented?
.
- Prev by Date: Re: Interacting with winlogon Desktop of Windows Vista
- Next by Date: Re: winsock + Schannel => Expired Intermediate Cert
- Previous by thread: RE: Major problems with UAC
- Next by thread: Re: How to work around UAC?
- Index(es):
Relevant Pages
|
