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).Quote:
Originally Posted by Arjay
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. :)
Well, yeah... but how do I get it? (I guess I'll keep digging.)Quote:
Originally Posted by Arjay
SHGetSpecialFolderPath will get you the current account path. Replace the current user name with the original and you've got it.Quote:
Originally Posted by ahmd
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
Nice, Igor! I take my hat off for you....Quote:
Originally Posted by Igor Vartanov
I didn't think about digging into the registry but it works like a charm. (Tested on both XP and Windows 7. Assuming Vista to work as well.) The [Session][DSK] in his example above gives the answer to my question.
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.
Hmm, so you're saying it's undocumented, hah? Is it just happened to be that MS was calling those registry keys for the Shell with a text representation of user SIDs?Quote:
Originally Posted by Igor Vartanov
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.Quote:
Originally Posted by Igor Vartanov
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?
Logged in user SID, not 'user token SID' whatever it is. And regarding 'do they?', I believe the answer is quite apparent. Yes, they do. Do load user's hive under textual SID name. I'm not sure what do you mean by 'security breach', but the key access is granted for SYSTEM, Administrators and user himself. Nobody else. Do you see any problem with security here?Quote:
So do they [at Microsoft] name registry keys with those text versions of user token SIDs?
Yes, I thought Microsoft were striving to achieve user account isolation with each new release of Windows. In this case, an unprivileged process can obtain a path to another user account (like your code has illustrated). And that's what I meant by a security breach. Before you posted your code I was about to reply that I was unable to find a solution to something that is impossible, but you beat me to it... Your approach was very cool though.Quote:
Originally Posted by Igor Vartanov
Sorry, but I still don't get it. Do you or don't you see a problem when user's hive is accessible for SYSTEM and Administrators? Are those 'unprivileged' or not in your vision of ideal security?