Global application settings for restricted users

[Dennis C. Drumm]

Is there one place (local xml file, registry, etc.) that all user can read
and write to??

I have some settings that applicable to all users, but when a restricted
rights user start my application, these global settings cannot be updated,
since it seems they cannot write to an xml or ini settings file in the
folder where the executing assembly runs from or to the HK_LOCAL_MACHINE
part of the registry.

If it comes to writing to, say an xml or ini file located in each user's
\Name\Local Settings\Application Data folder, then I would also need the
ability to search each of these files in each folder to check the supposed
global settings I am trying to maintain.

I'm sure there must be a way around this conundrum, but I'll be darned if I
can figure it out thus far.

Any comments or suggestions would be greatly appreciated,

Dennis

[Chad Z. Hower aka Kudzu]

"Dennis C. Drumm" <dc******@community.nospam> wrote in
news:eM**************@TK2MSFTNGP09.phx.gbl:

Is there one place (local xml file, registry, etc.) that all user can
read and write to??
Temp directory is always writabel, but of course not a good place for such.
If it comes to writing to, say an xml or ini file located in each
user's \Name\Local Settings\Application Data folder, then I would also
need the ability to search each of these files in each folder to check
the supposed global settings I am trying to maintain.

Look in the Applicatino opbject, there are pointers to the local and roaming directories along with
descriptions.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Get your ASP.NET in gear with IntraWeb!
http://www.atozed.com/IntraWeb/

[Dennis C. Drumm]

Well, I now see that if I can figure out how to change the permissions for
the xml configuration file to Full Control for the local Users group, then
all will work just fine. I know I will need to change the permission when
the program is installed and started the first time by the local
administrator. So that is what I am researching now.

If someone can steer me in the right direction, that would be great.

Thanks,

Dennis
"Dennis C. Drumm" <dc******@community.nospam> wrote in message
news:eM**************@TK2MSFTNGP09.phx.gbl...

Is there one place (local xml file, registry, etc.) that all user can read
and write to??

I have some settings that applicable to all users, but when a restricted
rights user start my application, these global settings cannot be updated,
since it seems they cannot write to an xml or ini settings file in the
folder where the executing assembly runs from or to the HK_LOCAL_MACHINE
part of the registry.

If it comes to writing to, say an xml or ini file located in each user's
\Name\Local Settings\Application Data folder, then I would also need the
ability to search each of these files in each folder to check the supposed
global settings I am trying to maintain.

I'm sure there must be a way around this conundrum, but I'll be darned if
I can figure it out thus far.

Any comments or suggestions would be greatly appreciated,

Dennis

[Steven Cheng[MSFT]]

Hi Dennis,

I also think using the NTFS's access control list to protect your
application's global configuration files is the proper approach. And as for
how to manipulate the NTFS permissions for file system, we can use the
buildin interfaces in the windows installer( can use in our install
project) or using script to manipulate the NTFS permissions. Here are some
certain reference on the related infos:

#How To Set Permissions Using the LockPermissions Table
http://support.microsoft.com/?id=288975

#How to use Xcacls.vbs to modify NTFS permissions
http://support.microsoft.com/?id=825751

Hope helps. Thanks,
Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Dennis C. Drumm]

Steven:

The problem with manipulating NTFS permissions at the time of installation
is that the application cannot thereafter recover from a corrupted or
deleted xml config file on its own.

I am afraid some wise guy will decide its fun to try and change app settings
by directly editing the xml file at some point. As it stands right now, I
have xml validation checks each time the file is opened and if it is found
missing, it will be re-created with default values.

So, I would like the program to be able to write and modify the file,
regardless of what permissions the user has.

Thanks,

Dennis

"Steven Cheng[MSFT]" <v-******@online.microsoft.com> wrote in message
news:iq*************@TK2MSFTNGXA01.phx.gbl...

Hi Dennis,

I also think using the NTFS's access control list to protect your
application's global configuration files is the proper approach. And as
for
how to manipulate the NTFS permissions for file system, we can use the
buildin interfaces in the windows installer( can use in our install
project) or using script to manipulate the NTFS permissions. Here are some
certain reference on the related infos:

#How To Set Permissions Using the LockPermissions Table
http://support.microsoft.com/?id=288975

#How to use Xcacls.vbs to modify NTFS permissions
http://support.microsoft.com/?id=825751

Hope helps. Thanks,
Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[WenJun Zhang[msft]]

Thanks for your response Dennis,

Yes, you're right. For normal desktop application, it'll runnin under the
logon user's account so that only the Administrators can use them to update
those proected configure files if we use NTFS permissions protection. (For
service application, we can configure it to running under a certain
account).
So if such NTFS restriction is not quite suitable to your app, I'm afraid
we could just let the configuration resource files available to all the
users, but provide additional SECRET and INTEGRITY protection. For
example, use symmetric or asymmetric algrithm to encrypt the file content
and use X509 certificat to digital sign the file(for prevent other ones
from modifying it).

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)