Difference between revisions of "Shared writeable folders"

Latest revision as of 15:39, 14 August 2012

Installation Issues

AquilaCRS (and most other Windows desktop software we produce) is designed to be installed per-user so that it can be automatically updated to perform such tasks as updating contents of drop down list boxes to meet the latest national dataset standards, or just to patch some potential security threat.

AquilaCRS therefore also stores it's data on a per-user basis, either by using the registry (now deprecated) or by using INI files (as per the latest MS recommendation).

We do not provide an "All Users" installation option. This is because there no longer exists a natural folder location that is shared between users and yet is still writeable.

The reasoning behind this is best explained in an article by Raymond Chen, Microsoft. I have reproduced (and slightly edited) it below. (Original Link)

When users ask for features that are security holes

If I had a nickel each time somebody asked for a feature that was a security hole...I'd have a lot of nickels.

For example, "I want a file that all users can write to. My program will use it as a common database of goodies."

This is a security hole. For a start, there's an obvious denial of service attack by having a user open the file in exclusive mode and never letting go. There's also a data tampering attack, where the user opens the file and write zeros all over it or merely alter the data in subtle ways.

A colleague from the MS security team pointed out another problem with this design: Disk quotas. Whoever created the file is charged for the disk space consumed by that file, even if most of the entries in the file belong to someone else. If you create the file in your Setup program, then it will most likely be owned by an administrator. Administrators are exempt from quotas, which means that everybody can party their data into the file for free.

If you have a shared resource that you want to let people mess with, one way to do this is with a service. Users do not access the resource directly but rather go through the service. The service decides what the user is allowed to do with the resource. Maybe some users are permitted only to increment the "number of times played" counter, while others are allowed to edit the song titles. If a user is hogging the resource, the server might refuse connections for a while from that user.

A file doesn't give you this degree of control over what people can do with it. If you grant write permission to a user, then that user can write to any part of the file. The user can open the file in exclusive mode and prevent anybody else from accessing it. The user can put fake data in the file in an attempt to confuse the other users on the machine.

In other words, the user can make a change to the system that impacts how other users can use the system. This sort of "impact other users" behavior is something that is reserved for administrators. An unprivileged user should be allowed only to mess up his own life; he shouldn't be allowed to mess up other users' lives.