This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bug report, question and suggestion

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:
"SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Perflib\\009
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 (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) */ 
	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, 
        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...


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]