Problem with granting permissions

[Jinspire]

Here is the code I used:

using system;
using system.Management;
using system.Management.Instrumentation;
using system.Security.AccessControl;

namespace Permissions
{

public static int Main(string[] args)
{
string strFolderPath = "c:\\Program Files\\Whaddeva\\";
string strUserName = "user@domain";

AddDirectorySecurity(strFolderPath, strUserName, FileSystemRights.FullControl, AccessControlType.Allow);
}

public static void AddDirectorySecurity(string Filename, string Account, FileSystemRights Rights, AccessControlType ControlType)
{
DirectoryInfo dInfo = new DirectoryInfo(Filename);
DirectorySecurity dSecurity = dInfo.GetAccessControl();
dSecurity.AddAccessRule(new FileSystemAccessRule(Account, Rights, ControlType));
dInfo.SetAccessControl(dSecurity);
}
}

The code doesn't exactly grant Full Control, but rather grants Special Permissions which effectively grant full control.

Now, since the effective permissions allow Full Control, one would expect the user to have permissions, right?

Wrong.

User gets 'access denied,' for some reason.

Ideas, anyone?

[nick.crane]

You can not programatically grant a user higher access rights than they have. For a basic user to have access to a folder during execution of your program they must already have access to the folder before the program starts.

However, it is possible to write an Installer class that is called as a custom action in your app installer to grand the user access permission to the folders they need. Since the installer must be executed by an Administrator it is as if the Administrator is giving the user the new folder access permissions.

There is also a command line app provided with the sdk that can set permissions but I cannot remember what it is just at the moment. However, it is intended for use during testing only.

[sknake]

Eh... I thought the format for domain user accounts was DOMAIN\Username . Apply the desired ACL rules in windows explorer then write code to dump out all access rules. Compare the ACL before/after the permission change and you will have your answer...

Also you could be inheriting deny permissions while explicitly adding full control, but as far as I know deny takes precedence over allow. That is probably something you should examine on your network.

If you want to ensure the user exists (and permissions are being applied properly) you could translate the security identifier instead of using string literal usernames:

NTAccount acct3 = new NTAccount(@"APEXSOFTWARE\Scott");
SecurityIdentifier sid3 = (SecurityIdentifier)acct3.Translate(typeof(SecurityIdentifier));