dotnet security: I have a service that logs/traces information through a custom trace listener
to a log file in System32. The name of the file is something like
ApplicationServerYYYYMMDD.log. Where YYYY is the year, MM is the month, and
DD is the day. So I get a maximum of one log file per day. When I was running
in the Administrator's group I had not problem, but when I tried to run under
an account that was only a member of the Domain Users group I received a
security exception when the service starts because it is trying to write to
the log file in System32. My question is two fold. How do I specify that my
service should only have permission to access (read/write/create) to the
files with the template above and no other FileIO Permission? Second, how do
I specify the ACL so that Domain Users can read/write/create these files in
System32 according to the template above? I don't know how and I am not sure
if it is possible to set permissions for files that don't exist yet but at
the same time I don't want to grant full control to Domain Users for the
System32 directory.

Ideas? Suggestions?

Thank you.

[quoted text, click to view]

You can't since declarative specification of FileIOPermission (e.g.: in a
RequestMinimum at the assembly level) must use a hard-coded path. That
said, you could create a sub-directory in system32 that is meant only for
your log files, then grant permissions to the directory rather than the
individual files.


[quoted text, click to view]

Same approach: create a subdirectory that is meant only for these files,
then set permissions on the directory.

[quoted text, click to view]

It is at the level of the directory that will be their parent. See
http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/13w2kadc.mspx
for a guide to the more complex ACL settings.


[quoted text, click to view]

Then don't. Use a subdirectory. And even then, why use the Domain Users
group? Instead, you should probably be creating another group to which
these permissions would be assigned. The service account could then be a
member of both the new group and the Domain Users group, granting it the
special permissions required by for the service as well as whatever other
permissions it needs on the domain.


[quoted text, click to view]