Running old apps as limited users - was: Accept Logon Button

From: Alun Jones [MSFT] (alunj_at_online.microsoft.com)
Date: 12/07/04 

Date: Tue, 7 Dec 2004 10:11:28 -0800

"Phillip Windell" <@.> wrote in message
news:Oge1cDI3EHA.3596@TK2MSFTNGP12.phx.gbl...
> "Steve Riley [MSFT]" <steriley@microsoft.com> wrote in message
>> Use Russinovich's REGMON and FILEMON tools to find out what these
>> poorly-written apps are trying to do -- usually write to HKLM. Then you
> can
>> maybe relax some permissions on those particular keys.
>
> Yea, I knew of those, but I just thought MS had some tool available to do
> this in a more convenient way. Maybe they can come up with something like
> that sometime :-)

What about the "Application Compatibility Toolkit"? Download it from
http://www.microsoft.com/windows/appcompatibility/default.mspx, run the
"Compatibility Administrator Tool", create a new database, add your chosen
program, and apply the "LUA" fix to it. This will at least get around the
HKLM and Program Files issues that Steve mentions above. You may also try
other compatibility fixes in that section.

On Windows Server 2003, you don't even need a download - right-click on the
executable (or a shortcut to it), and select "Properties". Click the
"Compatibility" tab. Check the box that reads "Allow non-administrators to
run this program".

Let me know whether that helps - I'd love to hear.

> Even when there are alternate choices it takes an "act of God" from those
> above to authorize changing the system,...and even if that is done the
> alternatives may have the same problem. The programmers that write this
> type
> of stuff, sometimes only seem to care about the thing doing the one narrow
> particular job it does and don't really care how it accomplished it or how
> it effects security.

That's the ever-present malaise that the industry is starting to wake up to.
Way back when, nobody ever tested applications. Then, when testing became
important, the testing consisted of making sure that the application did
what it was supposed to do when fed with correct data. That was okay,
because the user only screwed themselves up when they did something wrong
(some arrogance back then assumed that it was okay to punish the user for
being wrong!) Then we all connected to each other, and discovered that some
of us don't play nice.

Now, we test our applications with the deliberate intent of breaking, and/or
subverting them. There are some other companies that do this, too, but the
world hasn't yet completely woken up to the idea that you need to assume
that people are attacking you.

There's an old adage that "if we built buildings the way we write computer
software, the first woodpecker would destroy civilization". These days,
it's more like "if buildings had to be designed to cope with the sort of
attacks that are launched on computer software, they'd have to be
comfortable with pipe bombs being delivered by neighbourhood schoolchildren
at a rate of one per minute - and they'd have to do it without blocking the
driveway, and while keeping the floral border looking pretty". [Sometimes I
think it'd be useful if we could simply report the children to their
parents.]

Alun.
~~~~ 

-- 
Software Design Engineer, Internet Information Server (FTP)
This posting is provided "AS IS" with no warranties, and confers no rights.
Quantcast