Re: How to modify program files in Vista?

See below...
On Fri, 08 Aug 2008 11:35:55 +0100, Daniel James <wastebasket@xxxxxxxxxxxxxxxx> wrote:

In article news:<65ul94h3dv2qcj83r716q997hue9v7lks2@xxxxxxx>, Joseph M.
Newcomer wrote:
If there is an application ini file that is common to all users
there isn't really any provision to store that file in the prescribed
Windows file hierarchy.
****
There is a "common AppData" folder (CSIDL_COMMON_APPDATA) that does
this.
****

There is ... but that directory (C:\Documents and Settings\All
Users\Application Data, or something different on Vista) and any
directory created within it (by default, at least) is not writable by
non-Administrative users.

That's the point: There is no standard place for common WRITABLE files.
****
That's correct; it is extremely rare that anyone other than a sysadmin should be changing
default site settings.
****

An installer can, of course, change the permisions on any file or
directory it creates so the problem is far from insoluble. What I'm
getting at here is that without any clear guidance from Microsoft
everyone and his dog will come up with a different scheme and confusion
will ensue.

Generally, HKLM is used to set site defaults during installation
(which requires admin privileges) and is not changeable by ordinary
users. User data is kept in HKCU.

Again: agreed. But if one wants to create a registry entry that can be
accessed and updated by all users then one has little option but to
create it within HKLM and change the permissions. There isn't even an
HKU\AllUsers hive ...
****
Yes, but this is still considered a very rare situation. Generally, if you have
system-wide writeable data, it applies to system-wide files, and you either store the
global data as part of that file or as a separate file in the same directory as the shared
file, and you have to provide for synchronization to it by using either file-level lock
(open exclusive) or record-level locking (LockFileEx).
****

Generally, as a concept INI files suck (try storing a set of font
definitions in one, for example...painful!); I either use the Registry,
or if I want a file, an XML file.

Also true, but I was addressing the general problem that there isn't a
standard, recommended, location for ANY sort of writable data files
shared by all users.
****
Probably because the nature of the problem is that it is application-dependent as to how
this information must be maintained.
****

INI files have the advantage that most users with access to notepad can
understand how to edit them without breaking anything, which is not
necessarily the case with XML or other more structured file types. That's
also a DISadvantage, of course!

Individual users should not be allowed to modify global configuration
data.

I'm not talking only about configuration data in any strict sense. True
configuration data should be set up by some kind of administrator and not
altered by unprivileged users, of course.

There are plenty of other types of data that it is perfectly proper to
allow all users of a system to read and update ... and, yes, sometimes
these data are even held in INI files (though I agree that's not
necessarily a good choice).
*****
If the data is shared among users, note that .INI files cannot be locked, so you actually
have no idea what is in them at any instant, including partial changes.
*****

2. Place your INI file in the program directory, as you do at present,
but change your installation program so that it grants write access to
the INI file (ONLY the INI file) to all users.
[snip]
****
THe problem with this is that corporate security may detect a
writeable file and automatically reprotect it. Security policies
vary, but are often preemptive.
****

I've heard it suggested before that something along those lines might
happen. What "corporate security" applications do you know that will do
that? I'd be interested to know ...
****
I have consulted for several companies and this issue has already come up several times.
In fact, one of the things I was consulting on with one large organization was "security
audits", by which a program goes around every night and checks directory protections,
looks at file dates, etc., and if there are changes, essentially removes the MAC address
of the questioned machine from the allowable set of machines and requires human
intervention to reinstate it (they had been running this program for years, but it was
user-extensible and I was teaching them some techniques for doing plug-ins of their own
devising). I do not know what the program was, but the plugin interface was very simple.
We were writing a module that validated device drivers found on target machines against
the corporate list of approved device drivers. Another large organization had a program
that locked down "everything", and ran nightly from a central server. If it found
permissions that differed from what it thought were allowed, it created an exception
report that went to the security guru, who then confronted the machine user and questioned
why certain directories had their permissions changed.

The sizes of these sites varied from 1500 to almost 20,000 machines. The 1,500-machine
site had mission critical machines and if the machines failed, people could die because
Things Could Happen and without the machines to provide notifications, there were serious
risks that could not be identified or dealt with. This is the one for which we were doing
the driver audit. Unfortunately, NDA prevents me from saying more than this.
****

3. Create an application data folder in the all users profile folder
and write your INI file there. You will have to change the permissions
on this folder so that it can be written by normal users (but that's
less potentially risky than changing permissions in the Program Files
directory.
****
It if really is global data, yes, this would be the safest strategy.
But I doubt that it is truly global state; more likely it is per-user
state, improperly stored.
****

This is, in fact, what I do in one legacy application I maintain. The
files stored in the common writable area do include some per-user files
that could be stored elsewhere and some data that should really be
writable only by administrators ... but most of it is data that genuinely
is public and genuinely does have to be writable by all users.
*****
But .INI files would be a disaster because of the inability to lock them. There is no way
to guarantee a sequence of WritePrivateProfile... calls will update in a transactional
fashion. 2:Read, 2:Read, 1:Write 1:Write 2:Read 1:Write may result in inconsistent data
being seen by user 2. Therefore, this now falls into the category of application-specific
data manipulation and therefore is outside any "standards" that might be describable.
****

Unfortunately the data are (for historical reasons) all rather mixed
together so it's not really possible (without a major rewrite) to
separate the bits that could be per-user and the bits that should be
read-only from the rest.

Had I the luxury of a complete rewrite I should implement the back-end of
the application as a service and run that service under an account that
gave it access to all the necessary files. Each user could then update
the shared data under the program's control (after authenticating, etc.).

4. Use the registry. Create a suitable key in the HKLM hive for your
application and change the permissions on it so that all users can
write to it.
****
THe same security software that protects Program Files will often
reprotect HKLM. I've seen this happen once already.
****

I can't say I'm entirely surprised ... though it does seem a little
draconian, especially as there is no HKU\All Users.
****
Depends on whether or not people's lives and the success of your company depend on the
integrity of your system. "Draconian" to a home user can be somewhere between "barely
adequate" and "hopelessly inadequate" if the failure of your system leads to either death
of people or the death of your business.
joe
****

What's the software that does this?
****
I don't know the names of the products; at least one was a home-built setup by a large
organization but they had been running it since the days of NT4, and although I was told
the names of the other products (and I recognized one of them at the time as being run by
another company) I no longer recall them. I did this work about five years ago.

A number of "Site management" companies also provide software that does these things; that
is, you hire them to manage your site, and one of the things you get is their home-built
software which is part of their proprietary service. I know that one of the sites was
running this software because they had outsourced their site management to a major site
management firm.
joe
****

Cheers,
Daniel.


Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Default Permissions
    ... The default permissions on Windows Server 2003 are much tighter than they ... Please consult the Windows Server 2003 Security Guide ... for machines based on what the machines are doing. ...
    (microsoft.public.security)
  • Re: the exploit that wasnt
    ... The other Mac Book Pro? ... brought Microsoft into a security discussion about Mac OS X. ... The number of security patches, ... if you were to scan random machines on the internet for a week, how many Unix machines do you believe you would hit? ...
    (comp.sys.mac.advocacy)
  • Re: Cryptogram Comment
    ... Or had to go through setting up basic security for their ... > bother me with Windows questions. ... > machines are broken. ... and Linux and other open OS's make all patches FREE to redistribute. ...
    (sci.crypt)
  • Re: Temporary Ban On Links In Posts To SRI
    ... understand that there is a risk when clicking ... low)" in the general case does not apply to SRI. ... implement the security measures recommended. ... update" even with machines that are restricted to only applications ...
    (soc.religion.islam)
  • Re: the exploit that wasnt
    ... The other Mac Book Pro? ... brought Microsoft into a security discussion about Mac OS X. ... The number of security patches, ... if you were to scan random machines on the internet for a week, ...
    (comp.sys.mac.advocacy)