Vistamnesia (aka vistaphrenia)



  • Here I am, making my apps work with Vista, which involves, among other things, building them and "deploying" on test machine into appropriate locations, namely Program Files.

    Naturally, Visual Studio doesn't really work, and even if it did I would have to be threatened by physical violence to consider moving base of operations from XP box onto Vista. So I build stuff on XP, put it on the network drive, several of which are conveniently mapped on every windows box across the company, and then switch to Vista and copy them over into their Program Files locations for further testing. Not.

    User Abuse Control, being pretty good and otherwise sensible feature, asks me if I really want those files put into protected Program Files. Sure, say I, do so. Not so fast, says Vista, I forgot your drive mappings already.

    Here I am, copying files from network drive to local documents folder and then copying them from documents to program files...

    One would expect such an ubique feature to at least remember original environment across what supposed to be a single action. I don't want to think what happens with all the registry settings and just how many opportunities are there to shoot myself or user in a foot, or perhaps, a head.




  • Are you logged into the vista box as an admin, or as a restricted user, and using someone else's credentials for elevation?

    If you're logged into it as an administrator, and just elevate your privs to copy the files then IIRC it shouldn't lose any environment settings...

    If you're not though, the problem is that when you type in the password of another admin user to ''elevate'' your standard user account through UAC, it doesn't actually elevate anything, it just does a bog standard win2k style Run-As other user, hence no drives/environment/etc.

    This is IMHO a big problem, because it means that if you temporarily need admin privs to just install a per-user app for a limited user, you still have to do the same thing you did on win2k, which is manually run the control panel, make them an admin, run the installer as them, then set them back to a non-admin... maybe in windows 2009 they'll finally get it right :-(

    Anyway, If you want to solve your problem, either a) give yourself write-access to whatever subfolder of program-files you're using, or even just write-access to the binaries you're trying to overwrite, or b) make your life easier and don't run things out of program files when you're testing :-P
     



  • this isn't a wtf, this is your own snobbishness and prebuilt opinion that vista was going to suck. I have a 3 year old laptop and i have had the final version of vista on it since the day it got posted to msdn. I have had no problems with it other than a couple drivers for things i dont use anyways that will be fixed when Vista is actually publicly released at the end of this month. Visual Studio works great without a single problem so far.

     User Account Control can be turned off, and if Microsoft hadn't included it, then people like you would be here bitching about how its a wtf that vista didnt have any kind of protection and any program could do whatever it wanted.

    And instead of actually taking more than five minutes to learn how to actually use vista, you ran onto here and started bitching. You should save everybody the cliche complaints and switch to java. Then you could work on a mac. Haha.
     



  • @AustinW said:

    this isn't a wtf, this is your own snobbishness and prebuilt opinion that vista was going to suck.

    God forbid that Vista do what a user would expect. How snobbish of him that he would expect something to (logically) have one action rather than need an intermediate step. 



  • Yep, I'm running as admin, so all I have to do is click "continue".

    Nope, I don't mind clicking "continue" every time, I rather like feeling of control it implies, and I'm used to it on Linux and OSX.

    Yep, I would understand if this was happening during real "run as", with entering password and logging in as different user.

    Nope, I don't have problem I need fixed, I'm simply using direct \server\share path.

    The WTF is loosing drive mapping and who knows what other account-specific settings when simply allowing apps to use the permissions current account already has. Which implies that there is some kind of user-switching hack underneath.



  • Interesting to hear that you're an admin and it loses your mapped drives.

    I just mapped a drive, ran a standard command prompt, then did a runas-admin for another command prompt, and they could both access the mapped drive just fine.

    I'm running Vista RC2 not RTM though, so maybe they broke it :-) Raymond chen might be posting something about it in another 2 years on the oldnewthing :-)


  • Let me get this straight - you log on to Vista as UserA with a set of drive mappings, (effectively) switch credentials to UserB in order to perform a privileged operation, and wonder why UserA-specific settings are being lost?

    I've seen exactly the same thing happen on Unix-based platforms, when environment settings have been lost across an invocation of sudo. This is hardly a Vista-specific problem. 



  • @Cloaked User said:

    Let me get this straight - you log on to Vista as UserA with a set of drive mappings, (effectively) switch credentials to UserB in order to perform a privileged operation, and wonder why UserA-specific settings are being lost?

    I've seen exactly the same thing happen on Unix-based platforms, when environment settings have been lost across an invocation of sudo. This is hardly a Vista-specific problem. 

    Yes, but the point is that turning a quick and simple one-step process into a complicated multi-step one that initially fails without explanation, for some vague security, is a bad trade-off. How many people are going to know why things stop working when they put their superuser password in, and how to work around it? Versus getting fed up the third time and turning it off. Explaining the technical reasons why it can't be done isn't going to convince anyone, because you don't actually work at Microsoft and have no idea of whether this is an intractible problem or a really dumb design decision.

    But your ignorance is showing, because runas has had an /env switch for ages, to use the current user's network environment. It's not a remotely intractible problem, it's a solved one, it's just bad design on an otherwise good idea. And bad design on the part of unixes too. 

    Anyway, may I ask what part of the OP was flamebait enough to bring down a rabid vista-shill and a defeder of bad design? I didn't see any hostility, aside from making fun of a small glitch.
     



  • I have had no problems with it other than

    The Real WTF is people who use that phrase. 



  • Interesting that you're having this problem. I just tried copying from a network drive into my Program Files folder, and it worked fine. I'm running Vista Business. What are you running and what is the exact error message?



  • @AustinW said:

    User Account Control can be turned off, and if Microsoft hadn't included it, then people like you would be here bitching about how its a wtf that vista didnt have any kind of protection and any program could do whatever it wanted.

    Instead, we bitch about how it's a solution to the problem, but far from a good solution. In fact, bad solutions to problems are frequently the basis of WTFs. By the way, "you can turn it off" counts as a bad solution.
    @AustinW said:
    And instead of actually taking more than five minutes to learn how to actually use vista, you ran onto here and started bitching. You should save everybody the cliche complaints and switch to java.

    At least Java wouldn't require the user to answer a modal dialog every time the user takes an action that might have security implications. (Unless, I'm guessing, you run it in Vista.)
    @AustinW said:
    Then you could work on a mac.

    A what? Oh, you mean those computers that found a way to address security without interrupting the user every ten seconds with a dialog?



  • @Fred Foobar said:

    Interesting that you're having this problem. I just tried copying from a network drive into my Program Files folder, and it worked fine. I'm running Vista Business. What are you running and what is the exact error message?

    I think it might be specific to how the operation is done.  Could be done with Explorer, copy through cmd line, using win32 APIs, etc.  Each operation could result in a different result, depending on if the user is admin or not, if UAC is on/off, etc.  Too many permutations to count.  And he stated that he was an administrator, only elevating his privs, not changing users.  So assuming that the drive was lost, then it implies that there is some user-context switching going on here. And to note: mapped drives and environment are two completely different things.

    I've seen stranger things regarding mapped drives over the years.  I once had my cmd prompt/explorer show my z: drive as \\someserver\share and Visual Studio saw the same drive letter as \\someotherserver\share.  Only ever seen that once though. 



  • Visual Studio 2005 works on Vista perfectly fine.  I'd imagine Vs 2003 does too.  I've been running VS2005 Standard and VS2005 Express on a single machine with XNA for a few weeks now with no issue (just make sure you update to SP1!)

    You get an annoying thing about running as Admin, but that's probably a decent idea so people can understand.  What's the issue yo'ure having?  "It doesn't work" means nothing.

    Elevated Privileges are launched through svchost or some such like that.  Basically, svchost.exe launches consent.exe, which prompts the user for elevation.  If that goes through, it launches your application with a faked parent process that points to explorer.  Basically, there's no way of it to know your drive mappings.  Because of this, they appear to be lost because you're in another session.

    While I'm sure it's fun and exciting to be a condescending jerk about everything, it's also fun and exciting to learn why things are the way they are :)

    Yes, but the point is that turning a quick and simple one-step process into a complicated multi-step one that initially fails without explanation, for some vague security, is a bad trade-off. How many people are going to know why things stop working when they put their superuser password in, and how to work around it? Versus getting fed up the third time and turning it off. Explaining the technical reasons why it can't be done isn't going to convince anyone, because you don't actually work at Microsoft and have no idea of whether this is an intractible problem or a really dumb design decision.

    Because we know the average user runs a home network with a central file share...



  • I think the issue here is likely to be the same sort of thing I encountered yesterday in a thread on Slashdot. A PowerPoint user there was complaining that when he pastes a photo into a slide, it takes up massive memory and bogs down the system, but when he inserts the file it doesn't.

    Well, this is because the clipboard doesn't contain a reference to the file. It contains the actual data that was placed on the clipboard by whatever program you copied it from. Once upon a time, the only image format Windows understood was BMP, so whenever you put image data on the clipboard the average application converts it to BMP first. When you convert a photo from JPEG to BMP, it gets massively larger, and the RLE encoding BMP uses for compression not only doesn't work so well, but may actually make the image bigger.

    So what we have is someone saying "when I paste ten megs of BMP data into my slide, it bogs down the system, but when I insert a reference to a 500K JPEG file it doesn't". If someone brought you this as a problem, you would think they were retarded. Of course using twenty times as much data bogs down the system, dumbass. WTF?

    I think what's actually happening here is that the original poster is doing the Wrong Thing, but doesn't know it, because he doesn't understand the intricacies of the system that make his mistake obvious. And honestly, he shouldn't have to understand them - but whenever I run into this sort of problem, there is almost always an option that has been ignored for no good reason.

    Usually it's because the user is smart and creative, and has figured out a way to do this on previous versions of Windows where you couldn't normally do it. I used to use the SUBST command to make several hard drives look like one big filestore similar to UNIX partitions. That doesn't work anymore. I raised a lot of hell about it when it stopped working, but the fact is it was a retarded thing to do in the first place. The original poster will probably discover that there is a much easier and better way to do this that doesn't cause any problems whatsoever.

     



  • @CDarklock said:

    I used to use the SUBST command to make several hard drives look like one big filestore similar to UNIX partitions. That doesn't work anymore. I raised a lot of hell about it when it stopped working, but the fact is it was a retarded thing to do in the first place.

    You still can do that if you want to, so long as you're using NTFS. Just go into diskmgmt.msc, right-click the drive you want to mount, and click Change Drive Letter and Paths. It will give you the option to mount the drive in any empty NTFS folder, through the magic of NTFS reparse points. Another cool use of reparse points is NTFS Link, which gives you the ability to make hardlinks and symlinks sorta like in Linux. But in this case, hardlinks only work on files, and symlinks only work on directories. Just be sure not to set up an infinitely recursive file structure - Windows Defender, your antivirus software, and your backup program will all hate you for it. I figured that one out the hard way, when I mounted my backup drive in a subdirectory under my main drive, causing to to recursively back itself up until it ran out of space - like RAID 1, but decidedly more obnoxious.

    And it's not retarded, especially when you have one of those card readers, each of which feels the need to make itself its own drive. Solution: C:\Cards. Pretty cool.

     



  • @ShadowWolf said:

    Visual Studio 2005 works on Vista perfectly fine.  I'd imagine Vs 2003 does too.  I've been running VS2005 Standard and VS2005 Express on a single machine with XNA for a few weeks now with no issue (just make sure you update to SP1!)

    That's fine and all, and I'm happy VS works for you.... Has absolutely nothing to do with this post though :)

     

    Elevated Privileges are launched through svchost or some such like that.  Basically, svchost.exe launches consent.exe, which prompts the user for elevation.  If that goes through, it launches your application with a faked parent process that points to explorer.  Basically, there's no way of it to know your drive mappings.  Because of this, they appear to be lost because you're in another session.

    This is basically the issue he seems to be having. 

     

    Because we know the average user runs a home network with a central file share...

    No, but I can see this being a really annoying issue in a company that writes/tests software.  Developer A compiles something that they need to share with another developer, so they copy it to a network share.  Now person B needs to copy that file into their existing installation, but they have to copy the file to an unprotected location on the hard drive first.  Basically, all he's saying is that something that used to be a one step process, now became 2, and a very non-obvious 2 steps as well.



  • @CDarklock said:

    I think what's actually happening here is that the original poster is doing the Wrong Thing, but doesn't know it, because he doesn't understand the intricacies of the system that make his mistake obvious. And honestly, he shouldn't have to understand them - but whenever I run into this sort of problem, there is almost always an option that has been ignored for no good reason.

    Ok, people are getting WAY TOO defensive here.  Care to explain how he's doing the "Wrong Thing"?  How would you copy a file from location A to location B (Doesn't matter where A and B are located, as explorer obfuscates that nicely for us, and has done so for years)?  If there actually is an issue here (we haven't determined this yet), then why can't it do something like what IE does when you download a file, where it saves the file to temp somewhere, then when that is done, it copies the file to the desired location.  That would avoid this issue, albeit a little annoying.

    Alright, now instead of arguing, how about we work together? :) Does anyone know of any links docs that explain what happens under the hood of the UAC?   I'll be doing Vista stuff as well, and this type of information is really quite useful.  For example, I wonder if on Vista a user can be an admin, but there's actually a real Administator account that hides underneath, which is the account that runs when you elevate privs (like sudo to become root, etc)



  • @Fred Foobar said:

    Interesting that you're having this problem. I just tried copying from a network drive into my Program Files folder, and it worked fine. I'm running Vista Business. What are you running and what is the exact error message?


    Vista Business too.

    I think I have several unusual settings there. The account is roaming, belongs to a domain, member of administrators
    and debugging users, the drives are automapped during login, implicitly using this account's credentials (by applying some .reg file I believe). 

    Explorer is set to run each window in separate process.

    I'm using remote desktop from XP box.

    Error message says (when copying file from mapped drive D:\ ) "D: refers to a location that is unavailable. bla bla bla.".

    I don't enter password, I just click "continue" (2 times, +1 if overwriting :D)

    And this is not an unavoidable problem, I can use direct //server/share paths with no troubles. This is, however, a reason enough to bash Vista, which went the way of fancy GUI, instead of doing one of their most usefull features right.

    Looks like this is another case of leaking abstractions.



  • @ShadowWolf said:

    Visual Studio 2005 works on Vista perfectly fine.  I'd imagine Vs 2003 does too.  I've been running VS2005 Standard and VS2005 Express on a single machine with XNA for a few weeks now with no issue (just make sure you update to SP1!)



    Does debugger under VS 2003 work?

    Without debugger, VS is glorified editor and build management system. 



  • @CDarklock said:

    I think the issue here is likely to be the same sort of thing I encountered yesterday in a thread on Slashdot. A PowerPoint user there was complaining that when he pastes a photo into a slide, it takes up massive memory and bogs down the system, but when he inserts the file it doesn't.

    Well, this is because the clipboard doesn't contain a reference to the file. It contains the actual data that was placed on the clipboard by whatever program you copied it from. Once upon a time, the only image format Windows understood was BMP, so whenever you put image data on the clipboard the average application converts it to BMP first. When you convert a photo from JPEG to BMP, it gets massively larger, and the RLE encoding BMP uses for compression not only doesn't work so well, but may actually make the image bigger.



    So, you are saying, that the user is to blame for OS or apps implicitly and unnessesary converting data back and forth. And you are justifying it by historic reasons?? Don't shoot users for using one of the obvious ways you created for them, and hitting situations you didn't expect/chose to ignore. 



  • That's fine and all, and I'm happy VS works for you.... Has absolutely nothing to do with this post though :)

     I'm sorry?

     His first few lines were an overly sarcastic attack on VIsta regarding the fact that VS doesn't work on it.  He didn't specify a reason, so I'm saying that VS2005 does work for me.  It's 100% relevant.

    No, but I can see this being a really annoying issue in a company that writes/tests software.  Developer A compiles something that they need to share with another developer, so they copy it to a network share.  Now person B needs to copy that file into their existing installation, but they have to copy the file to an unprotected location on the hard drive first.  Basically, all he's saying is that something that used to be a one step process, now became 2, and a very non-obvious 2 steps as well.

     I can't.

    Why don't you use a normal directory structure relevant to the Vista world instead of being beligerant?  If he copied to his C:\Users\USER\Documents\Visual Studio 2005\Projects folder, he wouldn't be posting now or he could copy to C:\Program Data\something

    And really - the unfortunate thing is that it's very obvious at the moment, until Microsoft addresses this issue, there's really nothing you can do about it.  I'm not saying this is _not_ a problem - it is.  There's no reason why mapped drives should be lost - this is something that should be documented or something and it isn't.

    I'm familiar with this issue because I'm dealing with it at work :)

    Does debugger under VS 2003 work?

    Without debugger, VS is glorified editor and build management system. 

    Yeah - sorry, I'm not sure and don't have VS 2003 available to test.

    I haven't worked with VS 2003 for about 6 months now, so I don't keep it around :-\

    I know VS 2005's works though!  :-P

    Alright, now instead of arguing, how about we work together? :) Does anyone know of any links docs that explain what happens under the hood of the UAC?   I'll be doing Vista stuff as well, and this type of information is really quite useful.  For example, I wonder if on Vista a user can be an admin, but there's actually a real Administator account that hides underneath, which is the account that runs when you elevate privs (like sudo to become root, etc)

    The best place is to go to Channel9 and look around.  There's no information readily availabe at the moment, but if you nab the Kernel Debugger you can kinda step through what's going on (though it's a bit confusing and some of the structures aren't really available).

    At this point in time, I think the best thing might be to try to contact some MS bloggers and maybe contact the Vista Security Blog folk and see if you can't get some form of response out of them on the topic.

    Maybe if enough of us bug 'em about it, they'll do something on it is my thought.

    Trust me - not being able to access a mapped drive from an elevated process is a thorn in everyone's side, but the fact is that a lot of it comes from just doing this haphazardly and carelessly.

    Vista doesn't obfuscate things like XP SP1 did.  XP SP2 provides security controls you likely disabled or never ran in to because of the way Pro works (if you've used Home, you've probably encountered at least a couple of odd things from this).

    I'm not trying to make an argument here - but the original post and the following posts were not even trying to reach the problem or solution.  Just ignorant tirades on things because it's a Microsoft product and that's always fun to attack.

    I always say: "Think of the solution, not the problem".



  • Mystery Appears to be Solved!

    Found a video on sysinternals (http://www.microsoft.com/emea/itsshowtime/sessionh.aspx?videoid=360) that explains what happens.  I have a cool diagram, but it's on a whiteboard so I can't use it :(

    Anyway - basically here's what happens:

    When a user launches application.exe, Explorer goes out and tries to launch the program.  It calls in to Appinfo, which is a service running with svchost.exe, through an RPC call of some form.  Appinfo appears to determine whether a particular application requires elevation and, if it does, launches conset.exe, which asks for elevation from the user.  This is done under session0 in a "Secure Desktop" that can't be touched by any sort of application or program.  After the user provides administrative credentials (or clicks the "ok" button if they have an administrative token), AppInfo uses CreateProcessAsUser to create the process with the new credentials (http://msdn2.microsoft.com/en-us/library/ms682429.aspx).  At this point, your new application is remapped to appear that Explorer.exe is the parent process and the application is now back in Session1 so you can fully interact with it.

    It appears that AppInfo is invoked on any sort of CreateProcess call, so if you didn't elevate, the process would be Explorer -> AppInfo -> CreateProcessAsUser (note consent.exe removed from the equation).  This seems to preserve the drive mapping and that sort of thing.

    So in turn, it appears that this isn't a WTF at all, but rather a fudamental side effect from a change that was made in the security info of LocalSystem accounts - since those accounts can't access or use Mapped Drives, they can't persist or pass through the drive mappings to the applications when they elevate.



  • @ShadowWolf said:

    Mystery Appears to be Solved!

    Found a video on sysinternals (http://www.microsoft.com/emea/itsshowtime/sessionh.aspx?videoid=360) that explains what happens.  I have a cool diagram, but it's on a whiteboard so I can't use it :(

    Anyway - basically here's what happens:

    When a user launches application.exe, Explorer goes out and tries to launch the program.  It calls in to Appinfo, which is a service running with svchost.exe, through an RPC call of some form.  Appinfo appears to determine whether a particular application requires elevation and, if it does, launches conset.exe, which asks for elevation from the user.  This is done under session0 in a "Secure Desktop" that can't be touched by any sort of application or program.  After the user provides administrative credentials (or clicks the "ok" button if they have an administrative token), AppInfo uses CreateProcessAsUser to create the process with the new credentials (http://msdn2.microsoft.com/en-us/library/ms682429.aspx).  At this point, your new application is remapped to appear that Explorer.exe is the parent process and the application is now back in Session1 so you can fully interact with it.

    It appears that AppInfo is invoked on any sort of CreateProcess call, so if you didn't elevate, the process would be Explorer -> AppInfo -> CreateProcessAsUser (note consent.exe removed from the equation).  This seems to preserve the drive mapping and that sort of thing.

    So in turn, it appears that this isn't a WTF at all, but rather a fudamental side effect from a change that was made in the security info of LocalSystem accounts - since those accounts can't access or use Mapped Drives, they can't persist or pass through the drive mappings to the applications when they elevate.

    So, if you can get admin access to the machine and substitute your own version of conset.exe ...

     



  • @newfweiler said:

    So, if you can get admin access to the machine and substitute your own version of conset.exe ...


    I would expect it would be signed or otherwise protected... But if you can subvert that, you will be able to collect users' passwords. Except if you are admin already, it wouldn't help you much on compromized machine, maybe on other machines if they use same password everywhere (but then the password is likely to be "password123" anyway).

    Hm. But what makes conset.exe run in session 0?..



  • @ShadowWolf said:

    It appears that AppInfo is invoked on any sort of CreateProcess call, so if you didn't elevate, the process would be Explorer -> AppInfo -> CreateProcessAsUser (note consent.exe removed from the equation).  This seems to preserve the drive mapping and that sort of thing.

    Not if I am remembering right. I seem to remember reading somewhere that the way UAC works is like you described, but it gets invoked slightly differently:

    CreateProcess and other functions like it will try to launch the application, and AppInfo will just say whether or not it needs elevation. If it does, it returns some error, and that's it. If you use ShellExecute, however, it calls CreateProcess itself, and if elevation is needed, it does the AppInfo dance you described. The different behavior between CreateProcess and ShellExecute led to some annoying problems when trying to get to things under Cygwin, so I took the time to figure out what was going on. The end result was my small sudo program, which will get around that by calling ShellExecute.
     



  • Consent.exe is held by Windows Resource Protection or whatever - so if you did replace it, I'm not sure how far you'd get.  Maybe you could exploit that though.  It would be pretty dern tough.  It runs in session0 because it's called by AppInfo, which runs in session0.

    Not if I am remembering right. I seem to remember reading somewhere that the way UAC works is like you described, but it gets invoked slightly differently:

    CreateProcess and other functions like it will try to launch the application, and AppInfo will just say whether or not it needs elevation. If it does, it returns some error, and that's it. If you use ShellExecute, however, it calls CreateProcess itself, and if elevation is needed, it does the AppInfo dance you described. The different behavior between CreateProcess and ShellExecute led to some annoying problems when trying to get to things under Cygwin, so I took the time to figure out what was going on. The end result was my small <FONT color=#02469b>sudo program</FONT>, which will get around that by calling ShellExecute.

    Yeah, that does make a slight different as to whether you're getting elevation or not - but the process remains, generally speaking, the same.

    But I guess to be techincal, you only go through AppInfo if you use ShellExecute - otherwise it's just more of a query asking "Do I need elevation to run this?" and then CreateProcess handles it from there.  I do recall something on this topic, but not specifically what.  But the gist of it is exactly as you describe.



  • @Fred Foobar said:

    You still can do that if you want to, so long as you're using NTFS.

    I hate it when they do that. They kill something just long enough for me to stop using it, then quietly bring it back.



  • @CDarklock said:

    I hate it when they do that. They kill something just long enough for me to stop using it, then quietly bring it back.
    Reparse points have been available at least since Windows 2000, and SUBST is still working for me in Windows 2003R2...


Log in to reply