Say, my process requires elevation and it was run from a Standard User account (right-clicked and then Run As Administrator). How do I get a path to the desktop of that Standard user from such process?
Printable View
Say, my process requires elevation and it was run from a Standard User account (right-clicked and then Run As Administrator). How do I get a path to the desktop of that Standard user from such process?
What have you tried?
Everything possible in the book (that I know of). All of my attempts simply gave me an admin account info. Unfortunately there's no way, that I know of, to lower your own privileges (I even tried spawning a separate process, that unfortunately also ran elevated).
I thought maybe there's something in a logon token that can point to the actual user where the process was started from? (I don't know this subject that well.)
If you know the name of the original account, you can derive it from the admin account.
Very intresting issue. For some reason my gut feeling say that it's impossible to get that information though. :( I get the feeling that the original user is (kind of) not part of the process to start the application when you do run as.
I hope I'm wrong and this thread is definitely added to my subscriptions. :)
You could use "runas /env" to run as Administrator but keep the environment of the current user. I mean I've read in a magazine that in Windows7 you also could choose that option when right-clicking on an executable in the Explorer.
In any case that should give you access to all environment variables of the current user (maybe even access to the user registry) what should give you the user account somehow. Type 'set' in a command window to see all user environment variables.
See the sample. You should dig into registry in case you discover process owner sid differs from active user sid. Or in case you've made sure owner sid is built-in admin sid (well known sid).Quote:
Well, yeah... but how do I get it? (I guess I'll keep digging.)
Funny thing, Vista really differs from XP in this Run as Administrator thing:
XP
VistaCode:E:\Temp\564>564.exe
[Proc.Owner][SID] = S-1-5-21-1659004503-1326574676-839522115-500
[Proc.Owner][ACT] = IVARTANOV\Administrator
[Proc.User][SID] = S-1-5-21-1659004503-1326574676-839522115-500
[Proc.User][ACT] = IVARTANOV\Administrator
[Session][SID] = S-1-5-21-1659004503-1326574676-839522115-1003
[Session][DSK] = C:\Documents and Settings\Igor\Desktop
[Session][ACT] = IVARTANOV\Igor
Code:D:\Temp\564>564.exe
[Proc.Owner][SID] = S-1-5-32-544
[Proc.Owner][ACT] = BUILTIN\Administrators
[Proc.User][SID] = S-1-5-21-3531474516-4049177484-105061100-1000
[Proc.User][ACT] = IVARTANOV\Igor
[Session][SID] = S-1-5-21-3531474516-4049177484-105061100-1000
[Session][DSK] = C:\Users\Igor\Desktop
[Session][ACT] = IVARTANOV\Igor
Registry is very powerful thing if you really know what to look for.
Yes, that was another approach you could use. I can recall we already discussed the sample of running exe as interactive user (though it was related to services). Nothing changed since then: you find the active session user, find the process he owns, borrow the process token and run your own process with the token.Quote:
I even tried spawning a separate process, that unfortunately also ran elevated
Looking into registry is a real shortcut for the described procedure, I believe. With one 'but'... :) The shell folder registry things remain unchanged since Windows NT, but you know, there's no any guarantee MS won't change it in future.
Besides, I'd like to warn about another point which might be not very clear: the approach I sampled works only with interactive user. It's just because the user's hive is already loaded in by session start routine. Therefore, it's not possible to look for similar things with any user you wish until his profile gets loaded in somehow.
I'm saying that Explorer\Shell Folders key remains unchanged since Windows NT. At least for 14 years, as I started with Windows NT4.0. And sorry, my English seems not good enough to comprehend your last question.
I'm sorry.
You know when you call ConvertSidToStringSid to convert a SID from SID structure to a human readable string... So do they [at Microsoft] name registry keys with those text versions of user token SIDs? Wouldn't that be a security breach since any user account can read and interpret those?