How to allow user permissions over system folders

G

Guest

Guest
Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

Hi

We are running an old'ish application which was originally written to use
windows 2000 pro with a FAT32 hard disc.
We are now trying to upgrade the workstations to windowsXP with NTFS hard
disc.

This has posed a problem as the application tries to write to the root of
the C:\ drive as well as C:\windows, C:\windows\system and C:\windows\fonts.
The application fails because the user does not have permission to modify
these areas.

I am loathed to give the user permission over the whole of the c:\ drive and
the system folders in case they break anything.

These new systems can not use FAT32 as the hard discs are large, and the ris
build we use formats in NTFS anyway.

Can anyone advise a method of solving this problem?

thanks

M
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

"huff-n-puff" <huffnpuff@discussions.microsoft.com> wrote in message
news:B7F473F3-D0C4-419D-AD0D-4101E088129F@microsoft.com...
> Hi
>
> We are running an old'ish application which was originally written to use
> windows 2000 pro with a FAT32 hard disc.
> We are now trying to upgrade the workstations to windowsXP with NTFS hard
> disc.
>
> This has posed a problem as the application tries to write to the root of
> the C:\ drive as well as C:\windows, C:\windows\system and
> C:\windows\fonts.
> The application fails because the user does not have permission to modify
> these areas.
>
> I am loathed to give the user permission over the whole of the c:\ drive
> and
> the system folders in case they break anything.
>
> These new systems can not use FAT32 as the hard discs are large, and the
> ris
> build we use formats in NTFS anyway.
>
> Can anyone advise a method of solving this problem?
>
> thanks
>
> M

No easy solution here. It's easy to make the app work, but you lose
security. A couple of ideas though... use something like Virtual PC
(http://www.microsoft.com/windows/virtualpc/default.mspx) to create a second
'fake' PC that runs in a window on the real system. You then install
whatever you want on this virtual machine (completely different OS if you
want... Virtual PC actually simulates the hardware of a computer, so the OS
you run inside it thinks its on a real, physical computer.) If the user
screws it up, you can revert to the original saved image in a matter of
minutes. So basically it's like giving the user a second computer with more
relaxed security to run the app on, without the hardware cost and waste of
space on his desk. Takes a bit of disk space and decent RAM, but nothing
extraordinary.

Or, use a disk imaging product like Norton Ghost to capture an image of the
hard drive so that you can easily do a restore. The disadvantage here is
that if you or the user makes any legitimate changes to the system, you
would need to be constantly keeping your image up to date. With a virtual
system, I assume you wouldn't need to use it for anything other than the
legacy application.


--
Colin Nash
Microsoft MVP
Windows Shell/User
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

Your best bet, if you still have the source code, update the application and
make it NT compliant, otherwise, you're going to have to make a "security"
compromise, which always opens the door to other issues.

--
Star Fleet Admiral Q @ your service!
"Google is your Friend!"
www.google.com

***********************************************

"huff-n-puff" <huffnpuff@discussions.microsoft.com> wrote in message
news:B7F473F3-D0C4-419D-AD0D-4101E088129F@microsoft.com...
> Hi
>
> We are running an old'ish application which was originally written to use
> windows 2000 pro with a FAT32 hard disc.
> We are now trying to upgrade the workstations to windowsXP with NTFS hard
> disc.
>
> This has posed a problem as the application tries to write to the root of
> the C:\ drive as well as C:\windows, C:\windows\system and
C:\windows\fonts.
> The application fails because the user does not have permission to modify
> these areas.
>
> I am loathed to give the user permission over the whole of the c:\ drive
and
> the system folders in case they break anything.
>
> These new systems can not use FAT32 as the hard discs are large, and the
ris
> build we use formats in NTFS anyway.
>
> Can anyone advise a method of solving this problem?
>
> thanks
>
> M
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

Hi

Unfortunatly the app was created by a 3rd party, and the $$ signs appeared
over thier heads when we suggested an update to the app. so no go there.

I can not use Virtual Pc also because the app uses large sytem resoursces,
to the point where it is the only app on the machine.

Thanks

M

"Admiral Q" wrote:

> Your best bet, if you still have the source code, update the application and
> make it NT compliant, otherwise, you're going to have to make a "security"
> compromise, which always opens the door to other issues.
>
> --
> Star Fleet Admiral Q @ your service!
> "Google is your Friend!"
> www.google.com
>
> ***********************************************
>
> "huff-n-puff" <huffnpuff@discussions.microsoft.com> wrote in message
> news:B7F473F3-D0C4-419D-AD0D-4101E088129F@microsoft.com...
> > Hi
> >
> > We are running an old'ish application which was originally written to use
> > windows 2000 pro with a FAT32 hard disc.
> > We are now trying to upgrade the workstations to windowsXP with NTFS hard
> > disc.
> >
> > This has posed a problem as the application tries to write to the root of
> > the C:\ drive as well as C:\windows, C:\windows\system and
> C:\windows\fonts.
> > The application fails because the user does not have permission to modify
> > these areas.
> >
> > I am loathed to give the user permission over the whole of the c:\ drive
> and
> > the system folders in case they break anything.
> >
> > These new systems can not use FAT32 as the hard discs are large, and the
> ris
> > build we use formats in NTFS anyway.
> >
> > Can anyone advise a method of solving this problem?
> >
> > thanks
> >
> > M
>
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

huff-n-puff wrote:
> Hi
>
> We are running an old'ish application which was originally written to use
> windows 2000 pro with a FAT32 hard disc.
> We are now trying to upgrade the workstations to windowsXP with NTFS hard
> disc.
>
> This has posed a problem as the application tries to write to the root of
> the C:\ drive as well as C:\windows, C:\windows\system and C:\windows\fonts.
> The application fails because the user does not have permission to modify
> these areas.
>
> I am loathed to give the user permission over the whole of the c:\ drive and
> the system folders in case they break anything.
>
> These new systems can not use FAT32 as the hard discs are large, and the ris
> build we use formats in NTFS anyway.
>
> Can anyone advise a method of solving this problem?
>
> thanks
>
> M


This is quite common if the software was designed for Win9x/Me, or
if it was intended for WinNT/2K/XP, but was improperly designed. Quite
simply, the installation routine for this application doesn't "know"
how to handle individual user profiles, or the application tries to
make changes to "off-limits" sections of the registry. Quite often,
you can make this software available to other users by _copying_ the
Start Menu folder and Desktop folder shortcuts from the user profile
from which the software was installed in the corresponding folders in
the user profile(s) in which you'd like the software to be accessible.
If the application is something that can/should be made available to
all current and future users, copying the shortcuts into the
corresponding locations of the All Users profile will do the trick.

For some obscure reason, game developers in particular seem to not
understand WinXP's file security paradigm, and require even limited
users to have unnecessarily high privileges to protected systems
folders. For example, saved games are often stored in a sub-folder
under the game's folder within C:\Program Files - a place where no
inexperienced or limited user should have write permissions.

NOTE: This may not work if the software requires access to parts
of the hard drive and/or registry that are not normally accessible to
regular users. (This won't occur if the application was properly
written.) If this does prove to be the case, however, you're left
with two options: Either grant the necessary users appropriate higher
access privileges (either as Power Users or local administrators), or
replace the application with one that was properly designed
specifically for WinNT/2K/XP.

Some Programs Do Not Work If You Log On from Limited Account
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q307091

Additionally, here are a couple of tips suggested, in a reply to a
different post, by MS-MVP Kent W. England:

"If your game or application works with admin accounts, but not with
limited accounts, you can fix it to allow limited users to access the
program files folder with "change" capability rather than "read" which
is the default.

C:\>cacls "Program Files\appfolder" /e /t /p users:c

where "appfolder" is the folder where the application is installed.

If you wish to undo these changes, then run

C:\>cacls "Program Files\appfolder" /e /t /p users:r

If you still have a problem with running the program or saving
settings on limited accounts, you may need to change permissions on
the registry keys. Run regedit.exe and go to HKLM\Software\vendor\app,
where "vendor\app" is the key that the software vendor used for your
specific program. Change the permissions on this key to allow Users
full control."

--

Bruce Chambers

Help us help you:
http://dts-l.org/goodpost.htm
http://www.catb.org/~esr/faqs/smart-questions.html

You can have peace. Or you can have freedom. Don't ever count on having
both at once. - RAH