RE: Major problems with UAC
- From: lelteto <lelteto@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 14 Oct 2007 10:14:00 -0700
The Microsoft recommended solution is to store data instead of the Registry
in file(s) in those folders. So Yes, That's what I am saying.
Laszlo Elteto
Safenet, Inc.
"Mick" wrote:
Thanks Laszlo. Unfortunately that doesn't answer any of my questions..
Unless you mean that we should write data that is normally stored in
registry keys to a disk file in some 'special' folder somewhere. Is that what
you're suggesting?
"lelteto" wrote:
In Vista the recommended place to store system-wide configuration information
(or any data file) is systemdrive:\ProgramData\YourCompany\YourProduct\
folder.
Laszlo Elteto
SafeNet, Inc.
"Mick" wrote:
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?
How much sense does it make to have code that writes to HKEY_LOCAL_MACHINE
ghosted to some other location without any indication? (nerver mind, it's a
rhetorical question--with eyes rolled up)
Do DACLs work differently under Vista? If so, what are the differences and
where are they documented? Why doesn't a null DACL give all users access?
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?
- References:
- RE: Major problems with UAC
- From: Mick
- RE: Major problems with UAC
- Prev by Date: RE: Major problems with UAC
- Next by Date: Re: winsock + Schannel => Expired Intermediate Cert
- Previous by thread: RE: Major problems with UAC
- Next by thread: Re: Major problems with UAC
- Index(es):
Relevant Pages
|
