Manifests not working for control panel applets

[Tony Hoyle]

Hi,

I've been testing my app on vista beta 2 and have hit a roadblock with LUA.

One part of the app is a control panel applet. It exists solely to
configure global settings used by the service, so it needs access to
administrator priviliges to open the service control manager and to
write to HKLM.

When I started it as administrator it immediately barfed saying it
couldn't open the SCM. No problem... I setup a manifest in the file set
to requireAdministrator. This didn't work!

It seems that control panel applets don't respect manifests at all..
which means I'm screwed, basically.

I could rearchitect the file a bit.. I could do it with a priviliged
thread etc. but I can't see any way of doing it - the documentation
talks about rewriting the thing into a COM object (not an option given
the timescale and the amount of testing that would require), or passing
special flags to ShellExecute and running it as an external app - which
is messy, would require multiple windows to be up etc.

I even tried asking for the admin username/password & doing an
impersonate but LUA thwarts me again (my boss liked this version as he's
mostly an OSX user and wants a little padlock icon ideally.. can't see
how that would be implementable in LUA).

A similar problem exists with the server parts - several of them can be
run standalone as an unprivileged user (so I can't use
requireAdministrator), but there are operations that need admin access..
now these no longer work for administrators. I just need to elevate
privileges for maybe 2 or 3 instructions then back again.

How have others solved this?

Tony

 

[Josh]

Tony,

Can you post the Manfest file you used here? What setting are you using in
your manifest, higest available, what?


josh
http://windowsconnected.com

 

[Tony Hoyle]

Tony,

Can you post the Manfest file you used here? What setting are you using
in your manifest, higest available, what?

I eventually gave up... the manifest is correct (the same manifest in a
separate test executable produced an elevation dialog - albeit with
'unknown application' as the title), and the XP theming support works
just fine so it's being read.

I can see why - there's no way for an application to raise its own
privileges (even via LogonUser - tried that route.. there's no
CreateElevatedThread function either) - you have to create a new process
- and control panels are just DLLs running in the context of
control.exe, so can never be privileged.

MS seems to have got around this using HTML pages calling separate
applications... don't really have that option (since it wouldn't work
all the way back to NT4 which is a requirement for us).

Theres an executable in the system32 directory called
RunLegacyCPLElevated.exe which seems to work like rundll32... it's a
workaround for now... better than ditching vista compatibility efforts
completely.

The long term idea is to have a windows service running that takes
instructions from the control panel and makes changes as required, so
the app itself needs no privileges.. (now what would be really nice
would be a service that could create an elevated impersonation token for
a process... hmm...)

Tony