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).F ullName, 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.
Andreas Müller wrote: > [...] > 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).F ullName, > 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.
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.
> Andreas Müller wrote: >> [...] >> 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).F ullName, >> 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.
|
