Prev: what is kernelbase.dll ?
Next: How to inject a dll when a new process starts?
From: Corinna Vinschen on 30 Oct 2009 10:33
Hi,

Let's assume I have a file handle open on a file which has some nice
DACL with entries inherited from the parent directory.

So I call GetSecurityInfo() on the file to fetch the DACL, then I
iterate over the ACEs in the DACL using the GetAce function:

for (i = 0; i < ace_count; ++i)
if (GetAce (pAcl, i, &pAce))
[...]

When I examine pAce->AceHeader.AceFlags, the INHERITED_ACE flag is set
for the entries inherited from the parent dir.

Now I change my code to call NtQuerySecurityObject() instead of
GetSecurityInfo(). Then I iterate over the ACL the same way as above.

When I examine pAce->AceHeader.AceFlags, the INHERITED_ACE flag is *not*
set for the same entries.

Is the INHERITED_ACE flag not stored in the file's DACL on the file
system but constructed at run time within the GetSecurityInfo() function?

And if so, how does that work? When observing the file access using
Procmon, you can see that GetSecurityInfo() just calls
NtQuerySecurityObject() twice, once to find out the required buffer
size, once to fetch the actual security descriptor from the file.

However, calling NtQuerySecurityObject() the same way in the application
leads to the INHERITED_ACE flag missing in the AceFlags.

Can anybody explain this to me? Nothing in the MSDN man pages points to
this effect.


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
From: Alexander Grigoriev on 30 Oct 2009 22:28
Are you passing the same SECURITY_INFORMATION flags to NtQuerySecurityInfo?

"Corinna Vinschen" <corinna(a)community.nospam> wrote in message
news:hcetgc$d35$1(a)perth.hirmke.de...
> Hi,
>
> Let's assume I have a file handle open on a file which has some nice
> DACL with entries inherited from the parent directory.
>
> So I call GetSecurityInfo() on the file to fetch the DACL, then I
> iterate over the ACEs in the DACL using the GetAce function:
>
> for (i = 0; i < ace_count; ++i)
> if (GetAce (pAcl, i, &pAce))
> [...]
>
> When I examine pAce->AceHeader.AceFlags, the INHERITED_ACE flag is set
> for the entries inherited from the parent dir.
>
> Now I change my code to call NtQuerySecurityObject() instead of
> GetSecurityInfo(). Then I iterate over the ACL the same way as above.
>
> When I examine pAce->AceHeader.AceFlags, the INHERITED_ACE flag is *not*
> set for the same entries.
>
> Is the INHERITED_ACE flag not stored in the file's DACL on the file
> system but constructed at run time within the GetSecurityInfo() function?
>
> And if so, how does that work? When observing the file access using
> Procmon, you can see that GetSecurityInfo() just calls
> NtQuerySecurityObject() twice, once to find out the required buffer
> size, once to fetch the actual security descriptor from the file.
>
> However, calling NtQuerySecurityObject() the same way in the application
> leads to the INHERITED_ACE flag missing in the AceFlags.
>
> Can anybody explain this to me? Nothing in the MSDN man pages points to
> this effect.
>
>
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Project Co-Leader
> Red Hat


From: Corinna Vinschen on 31 Oct 2009 06:10
Alexander Grigoriev wrote:
> Are you passing the same SECURITY_INFORMATION flags to NtQuerySecurityInfo?

Yes, I'm just replacing one call with the other;

#define ALL_SECURITY_INFORMATION (DACL_SECURITY_INFORMATION \
| GROUP_SECURITY_INFORMATION \
| OWNER_SECURITY_INFORMATION)

DWORD w32_err;
PSECURITY_DESCRIPTOR psd1;
w32_err = GetSecurityInfo (fh, SE_FILE_OBJECT, ALL_SECURITY_INFORMATION,
NULL, NULL, NULL, NULL, &psd1);
if (w32_error == ERROR_SUCCESS)
{
[...]
LocalFree (psd1);
}

NTSTATUS status;
ULONG len = 65536;
PSECURITY_DESCRIPTOR psd2 = (PSECURITY_DESCRIPTOR) malloc (len);
if (psd2)
{
status = NtQuerySecurityObject (fh, ALL_SECURITY_INFORMATION, psd2,
len, &len);
if (NT_SUCCESS (status))
{
[...]
}
free (psd2);
}

> "Corinna Vinschen" <corinna(a)community.nospam> wrote in message
> news:hcetgc$d35$1(a)perth.hirmke.de...
>> Hi,
>>
>> Let's assume I have a file handle open on a file which has some nice
>> DACL with entries inherited from the parent directory.
>>
>> So I call GetSecurityInfo() on the file to fetch the DACL, then I
>> iterate over the ACEs in the DACL using the GetAce function:
>>
>> for (i = 0; i < ace_count; ++i)
>> if (GetAce (pAcl, i, &pAce))
>> [...]
>>
>> When I examine pAce->AceHeader.AceFlags, the INHERITED_ACE flag is set
>> for the entries inherited from the parent dir.
>>
>> Now I change my code to call NtQuerySecurityObject() instead of
>> GetSecurityInfo(). Then I iterate over the ACL the same way as above.
>>
>> When I examine pAce->AceHeader.AceFlags, the INHERITED_ACE flag is *not*
>> set for the same entries.
>>
>> Is the INHERITED_ACE flag not stored in the file's DACL on the file
>> system but constructed at run time within the GetSecurityInfo() function?
>>
>> And if so, how does that work? When observing the file access using
>> Procmon, you can see that GetSecurityInfo() just calls
>> NtQuerySecurityObject() twice, once to find out the required buffer
>> size, once to fetch the actual security descriptor from the file.
>>
>> However, calling NtQuerySecurityObject() the same way in the application
>> leads to the INHERITED_ACE flag missing in the AceFlags.
>>
>> Can anybody explain this to me? Nothing in the MSDN man pages points to
>> this effect.

Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
 | 
Pages: 1
Prev: what is kernelbase.dll ?
Next: How to inject a dll when a new process starts?