FileSecurity and UAC

  • Thread starter Thread starter Andreas Müller
  • Start date Start date
A

Andreas Müller

Hi NG,

i am having some trouble on a Windows 2008 Small Business Server and the
UAC. For our application we have a tool to set up some system settings and
write a file with some configuration information which is used for the
clients.
Because of the system settings changes the application needs Administration
privileges so I included a manifest file with '<requestesExecutionLevel
level="requireAdministrator">'. This works very fine, the UAC comes up and
everything works.

BUT, in the code I use the methods "Directory.Create" and "File.Create". If
this code is executed in the "elevated mode" the new directories and files
do NOT inherit their privileges from the parent. It is totally crazy, but
under the "normal user account" the directories and files are not readable,
althought the parent folders (and other files) are visible and readable by
everbody.

For the directories I was able to find a workaround:
Directory.CreateDirectory(path,
new
System.Security.AccessControl.DirectorySecurity(Directory.GetParent(path).FullName,
System.Security.AccessControl.AccessControlSections.All));
If is use this code, the directories behave as expected, the security
settings are inherited automatically. But if I only use
Directory.CreateDirectory(path) nobody (except elevated processes) can read
the directory.
I could live with this, but I have the same problem for newly created files
and the DirectorySecurity object can not be used while creating files.

Is there any global option I can set to tell my C# process that every newly
created directory or file should inherit the security settings from the
parent.

By the way, when I remove the manifest and execute the application without
the elevation every directory and file is readable, but then of course some
other things relating administrativ tasks will not work.

Regards
Andreas
 
Andreas said:
[...]
Because of the system settings changes the application needs Administration
privileges so I included a manifest file with '<requestesExecutionLevel
level="requireAdministrator">'. This works very fine, the UAC comes up and
everything works.

BUT, in the code I use the methods "Directory.Create" and "File.Create". If
this code is executed in the "elevated mode" the new directories and files
do NOT inherit their privileges from the parent. It is totally crazy, but
under the "normal user account" the directories and files are not readable,
althought the parent folders (and other files) are visible and readable by
everbody.

I'm not convinced this is "totally crazy".
For the directories I was able to find a workaround:
Directory.CreateDirectory(path,
new
System.Security.AccessControl.DirectorySecurity(Directory.GetParent(path).FullName,
System.Security.AccessControl.AccessControlSections.All));
If is use this code, the directories behave as expected, the security
settings are inherited automatically. But if I only use
Directory.CreateDirectory(path) nobody (except elevated processes) can read
the directory.
I could live with this, but I have the same problem for newly created files
and the DirectorySecurity object can not be used while creating files.

Sure. But that doesn't mean your program can't set the ACL information
for a file. It just means it needs to do so treating the file as a
file, not a directory.
Is there any global option I can set to tell my C# process that every newly
created directory or file should inherit the security settings from the
parent.

Not that I know of. For what it's worth, the behavior you're seeing
makes sense to me. When you run in elevated mode, your process looks
and acts like the specific admin account to the system. So files it
creates are owned by the admin, and should be accessible by the admin.
The way for that to happen when the files are written to a directory set
for a different user's access is to explicitly set the file permissions,
which is what is happening, as far as I can tell from your description.

Pete
 
Hi,

I found the problem. It was not my code but the system administrator ;-)

Normally our security settings are set to groups, also the option that
subfolders should inherit. In my special case the team which set up the 2008
test server is not very used to it yet, so they did a mistake. For the user
I used to test everything there was set a special security setting, with the
option, that subfolders should NOT inherit it.
When I now run my application, the owner of the new folder is my user, but
only the "admin-part" of the user. So the "normal" user was not able to
access the folders.
Just removing the special security settings also removed the problem.

So there was never a problem with my code, but thanks for the reply.

Regards
Andreas

Peter Duniho said:
Andreas said:
[...]
Because of the system settings changes the application needs
Administration privileges so I included a manifest file with
'<requestesExecutionLevel level="requireAdministrator">'. This works very
fine, the UAC comes up and everything works.

BUT, in the code I use the methods "Directory.Create" and "File.Create".
If this code is executed in the "elevated mode" the new directories and
files do NOT inherit their privileges from the parent. It is totally
crazy, but under the "normal user account" the directories and files are
not readable, althought the parent folders (and other files) are visible
and readable by everbody.

I'm not convinced this is "totally crazy".
For the directories I was able to find a workaround:
Directory.CreateDirectory(path,
new
System.Security.AccessControl.DirectorySecurity(Directory.GetParent(path).FullName,
System.Security.AccessControl.AccessControlSections.All));
If is use this code, the directories behave as expected, the security
settings are inherited automatically. But if I only use
Directory.CreateDirectory(path) nobody (except elevated processes) can
read the directory.
I could live with this, but I have the same problem for newly created
files and the DirectorySecurity object can not be used while creating
files.

Sure. But that doesn't mean your program can't set the ACL information
for a file. It just means it needs to do so treating the file as a file,
not a directory.
Is there any global option I can set to tell my C# process that every
newly created directory or file should inherit the security settings from
the parent.

Not that I know of. For what it's worth, the behavior you're seeing makes
sense to me. When you run in elevated mode, your process looks and acts
like the specific admin account to the system. So files it creates are
owned by the admin, and should be accessible by the admin. The way for
that to happen when the files are written to a directory set for a
different user's access is to explicitly set the file permissions, which
is what is happening, as far as I can tell from your description.

Pete
 
Back
Top