Setting DACL for Files and Folders

Sort of obscure question, hopefully someone has done this before. I've been able to use the EXPLICIT_ACCESS structure with SetEntriesInAcl and SetNamedSecurityInfo to modify the DACL information on a folder. No problems there.

Let's say I give some user all access--i.e. every named bit I can find I turn on in the EXPLICIT_ACCESS grfAccessPermissions field. Then I go to the folder, right click, choose properties, click on the Security tab, and for that user, the only checkbox marked is "Special Permissions". If I click the advanced button, the permissions are listed there for the user are "Full Control". There is an Edit button, so I click that, and all the checkboxes are marked off (all permissions on). But I want those checkboxes checked on the inital property page. After all, the user does have all access, doesn't he?

So I don't get discouraged, and instead I write a display function that walks the ACL list, and prints everything I can find on each ACE. Then I run the display function against the ACL that I created.

Next I go to the folder, choose properties, and select "Full Control". Apply the settings. Run my display program again, and compare the output. Something must have changed, right? Wrong. They are exactly the same.

So if my question isn't obvious yet, I want to know: how do you programatically set the checkboxes on the inital folder property page's security tab? By the way, when you are setting these values as a user, the normal way of doing it is to mark one or more of the checkboxes on the Properties->Security page, and that in turn causes a group of permissions to be set underneath (on the Advanced tab). So what I am seeing is a sort of inverse behavior--the values are set on the advanced tab but not on the usual tab that people generally look at.

Set EXPLICIT_ACCESS.grfAccessPermissions = GENERIC_ALL rather than setting every bit.

Do you believe that this will fix the problem, or are you saying that setting GENERIC_ALL is a shortcut that achieves the same result as setting every bit? If I remember correctly, GENERIC_ALL is a separate bit setting, rather than a mask of all bits. I can't test your solution at home, since I only have XP Home edition here...

Also, I've noticed that there is an absolute maze of API's for Security, for instance there is AddAce, RemoveAce, etc. which could be used instead of EXPLICIT_ACCESS to set up the DACL. I also noticed that the API's associated with EXPLICIT_ACCESS are in a different DLL. Does anyone know which API is more recent, or which is recommended? It would be annoying to find out that the API I chose is not recommended, or obsolete, etc, but whatever.

OK...I set GENERIC_ALL and I get all checkboxes marked. Fair enough. So I try setting GENERIC_READ for another user, expecting maybe Read to be checked off. No such luck. Is there any logic to this, or do I just have to try every combination until I figure it out?

OK...I think I'm getting the hang of this. To get the Read checkbox marked, you need to have

ea.grfPermissions = GENERIC_READ|FILE_READ_ATTRIBUTES|FILE_READ_DATA|F ILE_READ_EA;

And:

ea[ea_count].grfInheritance=OBJECT_INHERIT_ACE | CONTAINER_INHERIT_ACE;

I was setting OBJECT_INHERIT_ACE only for some ACE entries, and it immediately kicks it down to "Special Permissions". Probably similar issues for getting other permissions to work.

Kind of annoying, actually.

OK...things are going from annoying to really-f**ing bad. I have the function:

SetEntriesInAcl returning ERROR_NONE_MAPPED, which translates to:

"No mapping between account names and security IDs was done."

This doesn't happen all the time (it does happen every time for a particular call to SetEntriesInAcl, but not for my OTHER calls to SetEntriesInAcl). As the matter of fact, I think it only happens when the process is running as a service. Not entirely sure on that yet. But when I google the API call and the error, I don't find anything relevent. And the docs don't say anything about it. So I don't know what to fix.

To make matters worse, I ran across an opinion somewhere on the net where a guy says that SetEntriesInAcl and the other associated high-level API to the security code has a long history of being buggy and having poor performance(!). Does anyone know if a) this was true (nt4, corrected in some service pack maybe?), b) how true it was (how buggy was the API?), and c) is it still true with win2000, xp, server2003, etc.? Assuming that I do my part correctly, I really need this to work. It's not just for some toy app, and it would be annoying to have some API calls that are randomly failing...

Thanks for any info...

Quote:

---

To make matters worse, I ran across an opinion somewhere on the net where a guy says that SetEntriesInAcl and the other associated high-level API to the security code has a long history of being buggy and having poor performance(!).

---

They were certainly buggy several years ago. Whether they are still buggy I don't know. I would be hesitant to rewrite code when the problems probably lie elsewhere. If you do decide on a rewrite, you could consider using fksec.

Quote:

---

SetEntriesInAcl returning ERROR_NONE_MAPPED

---

ERROR_NONE_MAPPED is returned when a specified account can not be found. You should check the trustee information you are providing.

Your mention of failing in a service makes me wonder if you are running on a network domain? The "Local System" account where services often run, does not have network credentials. Therefore, it may not be able to look up an account on the domain. This may explain the problem if it runs as administrator but not as a service.

I'm not an expert on the Windows security API. You may need the help of specialised newsgroups (but try to ask specifc questions):
microsoft.public.platformsdk.security
microsoft.public.win32.programmer.kernel