1

I am not familiar with the various options you have when dealing with COM components. A legacy system in our company has published a COM API with a mixed mode dll to allow .NET components to interact with it.

It also allows the legacy system to run out-of-proc.

However, when setting up a simple windows app, it seems that both install and normal usage of the program needs Administrator privileges.

Is this a consequence inherently in deciding to use COM? Is this something we should be tweaking in the COM registration? I don't know much about this, but I know that there is a user/machine level separation.

Or should I be looking at the legacy system and assume that the demand for administrator privilege comes from something it does "on the other side" of the COM?

Tormod
  • 311
  • 2
  • 8
  • 1
    COM doesn't require administrator privileges to run. It's even possible to perform per-user installs without admin privileges. Something must not be quite right with the installer or package you're consuming. – RubberDuck Dec 13 '16 at 11:28
  • 2
    Looks to me like the COM component performs specific calls that require elevated permissions. – Wilbert Dec 13 '16 at 11:43
  • 1
    I'm voting to close this question as off-topic because it belongs on [Super User](http://superuser.com/). – David Arno Dec 13 '16 at 13:07
  • 2
    @DavidArno: COM is a binary-interop standard. The question's topic is analogous to dealing with troubles relating to language bindings, and is most definitely not Super User material, but belongs here. – whatsisname Dec 14 '16 at 06:18

2 Answers2

3

COM is at its core a binary-interface standard, allowing applications and libraries of different types to communicate with each other.

While it does have some security features, it's unlikely you are encountering those. With a few exceptions, calling into COM code is essentially the same as calling e.g. C code from Python, or any cross-language binding. There's a good chance there are key .net framework components that are wrappers around base windows services, connected via COM, which would mean an application might use COM without its developer even knowing it.

I've never used COMs security features, but I think you'd know it if that was the case. The features are for setting up convoluted user/role/security systems, and that would have to be well documented otherwise it'd be virtually impossible to accidentally hook it all up correctly into an application.

What is far more likely is that the particular COM components you are using require elevated permissions to do whatever they're doing. COM goes back to 1993, it's been built into a lot of stuff in the meantime, with a lot of it not playing nice with restricted permissions, which itself was a big problem when Vista came around, and onwards. This is especially likely when you say you are dealing with a legacy component.

You should definitely look first at the legacy component and see if it is doing some of the classic troublemaking maneuvers such as writing files to the Program Files or windows system directories.

whatsisname
  • 27,463
  • 14
  • 73
  • 93
2

COM has a very rich security feature set. Depending on how you set it up, accessing the component could require elevated permissions, or it may not; the component itself may require elevated permissions, or it may not, or it may impersonate an user with elevated privileges even if you call it from a user who doesn't have those privileges.

John Wu
  • 26,032
  • 10
  • 63
  • 84