Mail Archives: cygwin/2002/01/25/09:56:20
Corinna Vinschen wrote:
Hi Corinna, I have rearranged the order of your questions.
> The registry you're trying to access, is that a key below HKCU or
> HKLM?
Special keys:
HKLM
"SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Perflib\\009
and
HKEY_PERFORMANCE_DATA
Although the first key above is under HKLM, it is not a "regular"
key. There is an article (bug report) about it on the Microsoft
site, but I don't find it right away. The bug report is irrelevant
here, it's about trouble after reading the key 64k times.
> I see now that I don't know of which user you're talking here,
> the user who's *creating* the token or the user who's going to
> be *impersonated* by the token?
The impersonated one, after setuid()
No problem whatsoever with the creator ("self" in Microsoft language).
>In which situation does the application try to read the
> registry key, before or after the successful setuid() call? Does
> the application even try to read the registry key after setuid()
> or does a exec'd child process try to do that?
It fails after the setuid() and after a subsequent fork().
It succeeds after an exec()
After trying different things, I believe it fails because the
impersonated user does not have access to its own token. When
I NULL the token DACL (giving access to everyone) the impersonated
user can read the keys. Also after an exec() the usersid
appears in the token SD DACL.
> I have my own token print application which I changed to print
> the security descriptor (SD) of the token additionally. What I found
> was:
>
> - The owner returned by TOKEN_OWNER is the same as the owner of
> the token's SD.
>
> - The group returned by TOKEN_GROUP is the same as the group of
> the token's SD.
>
> - The DACL returned by TOKEN_DEFAULT_DACL is the same as the DACL
> of the token's SD.
That's what I see for the original process token. However it's
different for the impersonated token. What I see is that the default
DACL is exactly as expected from get_dacl() in security.cc (usersid
and system) but that the token SD DACL has admin and system, with
no access by the impersonated user of the impersonated token.
As I said above, when I clear the SD DACL as follows
/* Now clear the ACL */
if (!OpenThreadToken(GetCurrentThread(), WRITE_DAC,
TRUE, /* OpenAsSelf (self=process) */
&ThreadHandle))
printf("OpenThreadToken %ld\n", GetLastError());
if (!(InitializeSecurityDescriptor(&sd, SECURITY_DESCRIPTOR_REVISION) &&
SetSecurityDescriptorDacl(&sd, TRUE, NULL, FALSE)))
printf("SecurityDescriptor error %ld\n", GetLastError());
if (!SetKernelObjectSecurity(ThreadHandle,
DACL_SECURITY_INFORMATION,
&sd))
printf("SetKernellSecurity error %ld\n", GetLastError());
then the impersonated user can read the key. The right thing to do
of course is to build the correct DACL (usersid + system + admins)
instead of having a NULL DACL, which is what sec_user() is doing,
as far as I understand.
> So, actually there's no need to distinguish between the token and
> it's SD.
I don't understand what you mean...
Pierre
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -