Welcome Guest!
Create Account | Login
Locator+ Code:

Search:
FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

Free Trial Issue of Visual Studio Magazine

Lock Down Your Files (Continued)

The FileSecurity class contains a method named GetAccessRules that lets you read the discretionary ACL from the file. You build the sample application around DACLs instead of SACLs, so I won’t explain how to read or modify the system ACLs. However, you can accomplish this using the FileSecurity class’ GetAuditRules and SetAuditRules methods.

ADVERTISEMENT

The GetAccessRules method returns an object of type AuthorizationRuleCollection. This class holds one or more AuthorizationRule objects. The AuthorizationRule class is an abstract class and the base class for both AccessRule and AuditRule. When you call the GetAccessRules of a FileSecurity object, you get an AuthorizationRuleCollection containing FileSystemAccessRule objects.

Listing 1 enumerates the entries of the AuthorizationRuleCollection using a simple foreach loop, then creates a new form to show the rules on the screen (see Figure 3). This dialog is similar to the one Windows XP itself shows.

Edit ACLs
So far, you know how to read ACLs, but you also need to be able to edit them. For example, assume you want to change the permissions so that unauthorized people can’t read a confidential file. You can do this by using the sample application’s “Deny Read From Self” button (see Listing 2). You begin by using the WindowsIdentity.GetCurrent method to acquire the Security Identifier of the user running the application, then take advantage of the User property to get an instance of the SecurityIdentifier class.

At this point, the SecurityIdentifier represents the current user. Next, you create an instance of the FileSystemAccessRule class, the same instance you use when enumerating the DACL entries. The constructor accepts three parameters: the SID of the user or group to which you wish to assign permissions, the permissions you want to assign (using an enumeration of type FileSystemRights), and the ACE type (allow or deny).

Next, read the existing DACL from the file using the System.IO.File.GetAccessControl method, add the newly created FileSystemAccessRule to the returned collection, and then associate the new DACL with the file. Do this with the static SetAccessControl method that is the counterpart of the GetAccessControl method.

You can now read and write relevant permissions using the System.Security.AccessControl namespace. The next step is to use some of the new classes in this namespace to manipulate access control entries efficiently. For example, you can use the new classes to accomplish routine tasks such as converting user account names to SIDs, creating security descriptors (SDs) from SDDL language strings, and so on. You can see how to take advantage of several of these abilities by clicking on the sample application’s group box, “Low-level APIs.”

For example, you can take advantage of a combo box that lists all the well-known SID values in the system and lets you convert them to a SID string. A well-known SID identifies a generic user group or a generic user. Examples include the Administrator account, the Everyone group (“World” in SDK parlance), and Guests. In .NET, you can use the WellKnownSidType enumeration to access these values. The sample app populates the combo box with this code on start-up:

System.Array sids = System.Enum. _
   GetValues(typeof( _
   WellKnownSidType));
foreach (WellKnownSidType _    sid in sids) {    wellKnownSIDsComboBox. _      Items.Add(sid.ToString()); }

Clicking on the Show SID value button prompts the app to show the given well-known SID value on the screen as a string. Some well-known SIDs have a static presentation, which means they are the same from computer to computer (or domain to domain). For example, the WorldSid equals “S-1-1-0” everywhere. But some SIDs have a varying part in them that is associated with the current domain, or the non-existence of one, the computer. Thus, you cannot calculate these SID values without knowing something called the domain SID. The good news is that this domain SID is easy to extract because the SecurityIdentifier class has a property named AccountDomainSid that returns the domain SID from the given SID.

This article has provided a cursory introduction to the new System.Security.AccessControl namespace in the .NET Framework Class Library. Programming with the new classes is straightforward—once you have mastered the terminology and the class hierarchies. But once you do, you should be able to get going in no time at all.

A fun topic to explore next might include ACL manipulation when it comes to registry keys. The sample code that manipulates the files in this articles source code should prove helpful for solving that task as well. I recommend you study it carefully.

About the Author
Jani Järvinen works as a technical manager for software development at Moonsoft Oy in Finland. He is a C# Most Valuable Professional (MVP). E-mail him at .

Back to top














Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTP Home