Skip navigation

Icacls: The New and Improved Cacls?

The tool does more, lacks something important, but generally impresses

As every Windows administrator knows, NTFS permissions are some of our most useful weapons in the battle to keep our systems secure. In some cases, the Folder Options' Security tab offers an easy way to make minor permissions tweaks, but for repeatable or more complex jobs, the command line has always offered the most powerful tools, and in this case, the best one for the job has been Cacls—short for change access control list. However, Cacls has a few blind spots—for example, it's difficult to set permissions on a folder so that they're inherited. Because of these flaws, Microsoft might not include it in future Windows versions (although the tool is still around in Windows Vista).

Microsoft isn't leaving us out in the cold, though: Vista offers another permissions-focused command-line tool called Icacls. Just as Cacls does, Icacls lets you add or remove permissions, and at first glance Icacls appears to be a complete Cacls replacement. But it's not—it does a few things that Cacls can't do, and it lacks one extremely useful Cacls feature: You can't use it to hand-code a Security Descriptor Definition Language (SDDL) string. But in general, you'll find that Icacls improves upon Cacls.

How It Works
Icacls shows you a file's or folder's explicit and inherited file permissions, albeit in a somewhat encoded format. For example, if I create a file named test.txt, use the GUI to add an explicit Full Control permission for myself, and type

icacls test.txt 

I'll get the output that Figure 1 shows.

The first permission—vbus32\Mark:(F)—shows that a local account named Mark has Full Control permissions on the vbus32 system. (F is Icacls shorthand for Full Control, as it is for Cacls.) The next permission refers to the System account, but notice that its permission contains not only an F but also an I. The I tells you that System inherited the Full Control permission. Interestingly, there's no code for explicit permissions—only for inherited permissions. Icacls has many other codes, but let me highlight two more codes in Figure 1's example: M is the Modify permission, and RX comprises the Read and Execute permissions.

You can use the /grant option to give a file or folder a permission. In its simplest form, it looks like

icacls <file or folder name> /grant <useraccount>:  
  <permission> 

So, to give an account named Joe the power to delete test. txt, I could type

icacls test.txt /grant joe:d 

(Incidentally, case doesn't matter. I could also have typed JOE:D, Joe:D, or joe:D.)

Note that when you use Cacls to grant a permission, you also (by default) remove all previously existing permissions, including the inherited ones! You can fix that by adding the /E option to Cacls, but I've forgotten /E often enough to welcome Icacls' new syntax. In short, Icacls doesn't first remove all existing permissions before granting a new one. If, however, you want Icacls to first remove any permissions that a given user has before granting a new one, you can replace /grant with /grant:r. For example, if I were to give Joe the Modify permission by typing

icacls test.txt /grant joe:m 

and then give him Read and Execute permissions by typing

icacls test.txt /grant joe:rx 

then the command Icacls Test.txt would show me only Joe's Modify permission, because the Modify permission includes Read and Execute. But if I were to instead type

icacls test.txt /grant:r joe:rx 

Joe would have only Read and Execute.

You can use the /remove option to remove any explicit permission. (Icacls seems unable to remove inherited permissions.) To remove all of Joe's permissions, I'd type

icacls test.txt /remove joe

What's the "I" For?
I'm not quite sure what the "I" in Icacls stands for. Perhaps it means "inheritable" because the tool fixes the aforementioned Cacls problem, or maybe it means "integrity" because it lets you control Vista's integrity levels. Or maybe Icacls is just the Apple version of Cacls! Regardless, Icacls is a useful Cacls successor, but there's much more to it, as you'll see next month.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish