Re: HKEY_CURRENT_USER and CreateProcessAsUser w/o LoadProfile

[john]

According to MSDN:
http://msdn.microsoft.com/en-us/library/bb762281(VS.85).aspx
Note that it is your responsibility to load the user's registry hive into
the HKEY_USERS registry key with the LoadUserProfile function before you
call CreateProcessAsUser. This is because CreateProcessAsUser does not load
the specified user's profile into HKEY_USERS . This means that access to
information in the HKEY_CURRENT_USER registry key may not produce results
consistent with a normal interactive logon.

So, without loading the user profile, the result of accessing HKCU is
definitly not that user's hive. It's not .Default's hive either. .Default
belongs to the SYSTEM user. In my tests, it returns the original current
user's hive. Without the proper impersonation setting, allowing the thread
to access other user's hive is dangerous.

So is the enviroment blocks.

Regards,

"Joseph Galbraith" <Joseph.G...@nospam.nospam> wrote in message
news:DA9951F3-6AF3-4463...@microsoft.com...
> We have a service which sometimes calls CreateProcessAsUser() on behalf of
> connecting clients.
>
> Usually we do the LoadProfile thing and set every thing up as completely
> as
> possible; however, some of our customers have users with large roaming
> profiles, which take a long time to load. They would like an option to
> _not_
> load the users profile.
>
> If the users registry hive is _not_ loaded via LoadProfile() before
> calling
> CreateProcessAsUser() and the process does access HKEY_CURRENT_USER, what
> happens?
>
> Is it pointing to the .Default hive?
>
> If a process modifies HKEY_CURRENT_USER, what will happen?
>
> What about CreateEnvironmentBlock() ? If the users registry isn't loaded,
> does it use the .Default hive?
>
> Thanks,
>
> Joseph

[G�nter Prossliner]

Hello Joseph!

> I wonder if I manually load a scratch copy of the default hive into
> the HKU/<USER-SID> key if it will use that?

You can load the "ntuser.dat" file directly without loading the complete
user-profile. Of cause you have to perform some kind of "profile-lookup" to
get to the correct directory and to check if there is a profile for that
user, ...

see:

[RegLoadKey Function (Windows)]
http://msdn.microsoft.com/en-us/library/ms724889(VS.85).aspx

[Registry Files (Windows)]
http://msdn.microsoft.com/en-us/library/ms724873(VS.85).aspx

GP

[Joseph Galbraith]

"john" wrote:

> According to MSDN:
> http://msdn.microsoft.com/en-us/library/bb762281(VS.85).aspx
> Note that it is your responsibility to load the user's registry hive into
> the HKEY_USERS registry key with the LoadUserProfile function before you
> call CreateProcessAsUser. This is because CreateProcessAsUser does not load
> the specified user's profile into HKEY_USERS . This means that access to
> information in the HKEY_CURRENT_USER registry key may not produce results
> consistent with a normal interactive logon.
>
> So, without loading the user profile, the result of accessing HKCU is
> definitly not that user's hive.

Yes, I had read that in MSDN too; and like I said, generally we do "all the
right stuff (TM)" But, unfortunately, for some use cases, all the right
stuff is too expensive.

>It's not .Default's hive either. .Default
> belongs to the SYSTEM user.

That's good to know. I suspected something along those lines, but wasn't
sure.

> In my tests, it returns the original current
> user's hive. Without the proper impersonation setting, allowing the thread
> to access other user's hive is dangerous.

Ugh... that would be a hole big enough to drive a truck through. I was
hoping for something intelligent... like it uses .default but does some
'redirection' magic so we get our own private copy... but I guess not.

I wonder if I manually load a scratch copy of the default hive into the

HKU/<USER-SID> key if it will use that? I guess it's time to start writing
test code.

> So is the enviroment blocks.

Yeah... I sorta figured. Again, I wonder if CreateEnvironmentBlock() will
use a hive loaded into HKU/<USER-SID> manually rather than through
LoadUserProfile().

Thanks,

Joseph

[Ben Voigt [C++ MVP]]

>> In my tests, it returns the original current
>> user's hive. Without the proper impersonation setting, allowing the
>> thread
>> to access other user's hive is dangerous.
>
> Ugh... that would be a hole big enough to drive a truck through. I was
> hoping for something intelligent... like it uses .default but does some
> 'redirection' magic so we get our own private copy... but I guess not.

Somehow I doubt that the new process gets improper access to the other hive.
ACLs are still in effect. OTOH having HKEY_CURRENT_USER point somewhere
that's (largely) not readable or writable can't be conducive to running most
programs, and that's what I expect would happen.