Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Registering a COM dll without administrator privileges

121 views
Skip to first unread message

Brian Muth

unread,
Feb 20, 2003, 5:23:29 PM2/20/03
to
A question for my fellow MVP gurus:

A potential client is very suspicous about the automatic registration of COM
objects that are downloaded and registered through the browser.
Specifically, unless the use has local administrator privileges, the
registration step fails because he lacks access rights to the registry.

Specifically,
http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b190686 seems to
describe the issue.

What are the minimum registry access rights required?

The article describes that ATL7 seems to correct the problem, however, I've
tested a control built under Dev Studio.NET and the registration fails for a
regular local user.

I seem to recall reading somewhere that there is an alternate registry
location under HKEY_CURRENT_USER that can be used. Is this so?


Igor Tandetnik

unread,
Feb 20, 2003, 5:59:07 PM2/20/03
to
"Brian Muth" <bm...@straightthrough.com> wrote in message
news:uJ3Kz6S2...@TK2MSFTNGP12.phx.gbl...

> I seem to recall reading somewhere that there is an alternate registry
> location under HKEY_CURRENT_USER that can be used. Is this so?

'Tis so in Win2K and above. See

http://msdn.microsoft.com/library/en-us/sysinfo/base/hkey_classes_root_key.asp
http://msdn.microsoft.com/library/en-us/sysinfo/base/merged_view_of_hkey_classes_root.asp

--
With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken


Brian Muth

unread,
Feb 20, 2003, 8:40:59 PM2/20/03
to
Much obliged, Igor. Just what I was after. Many thanks.


Brian Muth

unread,
Feb 21, 2003, 3:00:23 AM2/21/03
to
The saga continues....

I've modified the <Myclass>.rgs file from

HKCR
{
<etc.>
}

to

HKCU
{
'Software'
{
'Classes'
{
<etc.>
}
}
}


This part appears to register correctly by a user without local
administrator rights. However, later in the code the call to
AtlModuleRegisterTypeLib fails. It appears to fail at
::RegisterTypeLib(pTypeLib, bstrPath, szDir), which still needs
administrator rights.

Has anyone gone down this path before? Documentation seems very scanty.

Any suggestions regarding a fix?

"Brian Muth" <bm...@straightthrough.com> wrote in message

news:e696JpU...@TK2MSFTNGP09.phx.gbl...

Igor Tandetnik

unread,
Feb 21, 2003, 10:50:15 AM2/21/03
to
I'm afraid there is no better way than to figure out exactly what
registry changes RegisterTypeLib makes for your type library, and move
them by hand into the .RGS script with appropriate modifications.

--
With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken

"Brian Muth" <bm...@straightthrough.com> wrote in message
news:eyF1E9X2...@TK2MSFTNGP10.phx.gbl...

Brian Muth

unread,
Feb 21, 2003, 12:25:52 PM2/21/03
to
I have come to the same conclusion.

I'm getting the impression from my Google searches that NOBODY has really
seriously tackled this issue. I'll post to microsoft.private.mvp.visualc to
see if Microsoft takes an interest. This is clearly a problem when one has
15 COM objects to modify.

Thanks again, Igor.


David McCabe

unread,
Mar 21, 2003, 6:54:59 PM3/21/03
to
For what it's worth now (and I apologise for replying to an old post,
but I thought it was relevant):

You can get around this problem on Windows 2000 and later by
overriding the DllRegisterServer and DllUnregisterServer methods
generated by ATL and using the new function RegOverridePredefKey, made
for this very purpose.

[module(type=dll, etc.) ]
class CPerUserRegisterDllMain
{
public:
BOOL DllRegisterServer()
{
HKEY hKeyCurrentUser;

RegOpenKeyEx(HKEY_CURRENT_USER, _T("Software\\Classes"), 0,
KEY_ALL_ACCESS, &hKeyCurrentUser);
RegOverridePredefKey(HKEY_CLASSES_ROOT, hKeyCurrentUser);
RegCloseKey(hKeyCurrentUser);

return __super::DllRegisterServer();
}

BOOL DllUnregisterServer()
{
HKEY hKeyCurrentUser;

RegOpenKeyEx(HKEY_CURRENT_USER, _T("Software\\Classes"), 0,
KEY_ALL_ACCESS, &hKeyCurrentUser);
RegOverridePredefKey(HKEY_CLASSES_ROOT, hKeyCurrentUser);
RegCloseKey(hKeyCurrentUser);

return __super::DllUnregisterServer();
}
};

--
David McCabe

"Brian Muth" <bm...@straightthrough.com> wrote in message news:<eyF1E9X2...@TK2MSFTNGP10.phx.gbl>...

Pranish Kumar [VC++ MSFT]

unread,
Mar 31, 2003, 2:56:15 PM3/31/03
to

--------------------
>From: "Brian Muth" <bm...@straightthrough.com>
>Subject: Re: Registering a COM dll without administrator privileges
>Date: Fri, 21 Feb 2003 09:25:52 -0800
>Lines: 10

We're looking into ways to solve this problem at development time. However,
we have not been able to get traction on this as a real issue for
production applications. Do people feel strongly about this?

--
Pranish Kumar
pran...@microsoft.com
Microsoft Visual C++ Team
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Brian Muth

unread,
Mar 31, 2003, 4:21:11 PM3/31/03
to
I have found this to be a definite problem, Pranish.

Our company actually lost the bid on a contract on this issue alone. We
stipulated that our downloadable COM objects could only be installed if the
end user had local administrator privileges. This tilted the decision in
favour of a Unix-J2EE solution, even though we had a ready product vs. a
longer development cycle for the winning proposal.

Our company targets the corporate financial sector, many of whom favour
Unix-based platforms and J2EE solutions. We often have to fight preconceived
notions about Microsoft technology. I would have liked to have made our COM
objects a bit more friendly for such environments. (We probably will one
day, but the coding effort for 15 or 30 controls is not insignificant given
our current resources.)

Cheers,

Brian Muth (MVP)


Brian Muth

unread,
Apr 1, 2003, 1:52:52 PM4/1/03
to
This is really surprising that there are no posts.

Does this mean everyone sets up their network such that users have local
administrator rights? I can't believe it!


Kim Gräsman

unread,
Apr 1, 2003, 2:11:23 PM4/1/03
to
Brian,

The way I see it, I don't personally need it, since I live on the server
side.

But the fact that it seems to be impossible/very hard given today's
circumstances is a bit disconcerting.

The security initiative would do good in respecting COM for a while longer,
I guess - given the popularity of this group, many people are still building
components/controls in ATL, and if only half of them end up on clients,
there's going to be a problem, since people are more security conscious now
than they were back in -98.

Kim


"Brian Muth" <bm...@straightthroughnospam.com> wrote in message
news:eaUfn$H#CHA....@TK2MSFTNGP10.phx.gbl...

Craig Powers

unread,
Apr 1, 2003, 2:20:17 PM4/1/03
to

It's not been an issue for our software. I think the clients who are
more restrictive also tend to do their own special installation
packaging, which allows them to evade the issue. For our internal
users, they're moving to making the users members of the Power Users
group -- I'm not sure which priveleges that confers, but I can say
that it's enough for them to install our software (which includes
registration of several OCX controls and registration of at least
one VB ActiveX dll) without incident.

--
Craig Powers
MVP - Visual C++

Jeff Kohn

unread,
Apr 1, 2003, 5:45:15 PM4/1/03
to
Doesn't this pretty much invalidate the whole concept of a secure registry?
Unless I missed something, what's to keep malicious code from using this
same approach?

Jeff

"David McCabe" <da...@sunlightd.com> wrote in message
news:ad268c21.03032...@posting.google.com...

Igor Tandetnik

unread,
Apr 1, 2003, 5:59:31 PM4/1/03
to
How? This technique just allows the code that is hardcoded to use
HKEY_CLASSES_ROOT to write to some alternative key instead (and it still
needs sufficient access to write to this alternative key). It does not
open up HKEY_CLASSES_ROOT to underpriviledged code. In particular, COM
object installed by guest user cannot register itself machine wide so as
to get to run with elevated priviledges when an administrator logs in
later - it is only registered under HKEY_CURRENT_USER key of this guest
user.

--
With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken

"Jeff Kohn" <jk...@bindview.no-spam.please.com> wrote in message
news:O7KvEBK#CHA....@TK2MSFTNGP11.phx.gbl...

Alexander Nickolov

unread,
Apr 1, 2003, 6:05:24 PM4/1/03
to
Well, no, it'll write in HKCU, where anything started from the interactive user
can write anyway. Security is not compromised.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnic...@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

"Jeff Kohn" <jk...@bindview.no-spam.please.com> wrote in message news:O7KvEBK#CHA....@TK2MSFTNGP11.phx.gbl...

0 new messages