VS2005/Vista issues
in [MFC]
|
From: Joseph M. Newcomer on 18 Jun 2007 22:39 Which is exactly the rationale I'm applying. I don't want to deliver a product that fails in the field once deployed because it ran fine for me as admin, but won't work for anyone else. What I want to do is twofold: Never, ever have to explicitly run a program "as administrator" if I always want run it as administrator; double-clicking the icon will ask me if I want to elevate, and I will click "continue" or "yes" or "ok" or whatever is required Never, ever have to supply a password in response to a privilege elevation prompt joe On Mon, 18 Jun 2007 09:34:02 -0700, "Tom Serface" <tom.nospam(a)camaswood.com> wrote: >Yeah, that is easy for C++ programmers to say. Try debugging and ASP.NET >application on Vista without running VS 2005 as an administrator... I find >it annoying to have to remember to do that every time I am working in one >environment as opposed to another and so far I haven't been able to figure >out a way to run "As administrator" all the time so I always have to right >click and select the item. I guess I could turn off UAC, but that would >make me run differently than my users and I'm sure I'd discover all kinds of >things that would be wrong with that approach as soon as people started >testing my release builds :o) > >Tom > >"Anthony Wieser" <newsgroups-sansspam(a)wieser-software.com> wrote in message >news:eoZxmEcsHHA.5008(a)TK2MSFTNGP03.phx.gbl... >> How about you change your account type to admin to install VS2005, so the >> correct profile gets updated when you install VS2005, and change it when >> you find you really need admin privileges, but then revert back to limited >> when you don't... Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 18 Jun 2007 22:40 That's what I was trying to determine. Was it correct or not? If it is not correct, then my solution is simple, as you suggest. joe On Mon, 18 Jun 2007 13:37:26 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:g59d73luv7ul8a21lpqio7fsgnsr1j4rhq(a)4ax.com... >> This question was based on the earlier reply in this thread: >> >>>Actually there is BIG difference. A "limited" process running under >>>administrator account can open a handle to an "elevated" process with full >>>access rights and screw with it any way it wants - run a remote thread, >>>inject code, etc. It's like being on the other side of the fence, but >>>still >>>having a key to the gate. So it's just an illusion of protection. >>> >>>A process running under "true" limited user CANNOT open handle to an >>>administrator process. It even cannot send arbitrary windows messages to >>>it. >> >> This suggests that if I make myself an administrator account (add my >> account to the >> administrator group) then I would NOT be subjected to the limitations of >> my current >> account. I want code that runs under my login account to have all the >> llimitations of an >> ordinary user (including to being able to set hooks, etc.), but if I run a >> program that >> wants privileges (as specified in its manifest) then it will prompt me, >> and I can simply >> click one mouse button to get them, so I can do the things I need to do >> without massive >> hassle while still getting a credible representation of what end users >> will normally see. >> joe >> > >Yes, and I pointed out that the assertion you quoted is simply wrong, in my >experience. SetWindowsHookEx() does install a global hook, but you will see >your DLL does *not* get injected into elevated processes, if the injector is >not elevated. > >-- David > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Ching on 19 Jun 2007 02:11 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:lfge731i9ir7396lr1308kk07b13970e25(a)4ax.com... > That's what I was trying to determine. Was it correct or not? If it is > not correct, then > my solution is simple, as you suggest. I don't know why you don't take my word for it, regarding the SetWindowsHook. I've tried it, and it works exactly I described. If you want to try the other API's like VirtualAlloc, CreateRemoteThread, etc. then try it using the SendMessageRemote() function that I offered before, and I believe you tried on other OS's. Myself, I'm not worried about it. I have my Admin account, have UAC enabled, and that's what I program in. My main dev machine is Vista running exactly this. -- David
From: David Ching on 19 Jun 2007 02:16 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:cage73tj26cvekaikuokodvhn3gkag6niq(a)4ax.com... > Which is exactly the rationale I'm applying. I don't want to deliver a > product that fails > in the field once deployed because it ran fine for me as admin, but won't > work for anyone > else. > > What I want to do is twofold: > Never, ever have to explicitly run a program "as administrator" if I > always want > run it as administrator; double-clicking the icon will ask me if I want > to elevate, and I will click "continue" or "yes" or "ok" or whatever > is required > Never, ever have to supply a password in response to a privilege elevation > prompt Right-click the shortcut (e.g. to DevEnv.exe) and click on Properties. Click the Shortcut tab. Then click the Advanced button. Check "Run as administrator." Now everytime you click the shortcut, it will elevate automatically. An Admin account doesn't prompt for a password to elevate. If running in an Admin account is suspect, then create another account called Limited and try your program there before delivering it. That's what I do and it works great. -- David
From: Tom Serface on 19 Jun 2007 02:16
Yep. There is a problem with MFC and it's attempt to write the icon information to the registry, but at least it doesn't assert if it can't do it so if users install and run at least once as an administrator it will work from that point on. However, very few other things in my programs ever need any specific privileges beyond accessing the user's files. Tom "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:cage73tj26cvekaikuokodvhn3gkag6niq(a)4ax.com... > Which is exactly the rationale I'm applying. I don't want to deliver a > product that fails > in the field once deployed because it ran fine for me as admin, but won't > work for anyone > else. > > What I want to do is twofold: > Never, ever have to explicitly run a program "as administrator" if I > always want > run it as administrator; double-clicking the icon will ask me if I want > to elevate, and I will click "continue" or "yes" or "ok" or whatever > is required > Never, ever have to supply a password in response to a privilege elevation > prompt > joe |