| View previous topic :: View next topic |
| Author |
Message |
bornsoft
Contributor
Joined: 19 Feb 2009
Posts: 113
Location: Germany
|
 Posted: Wed Feb 24, 2010 12:14 am Post subject: |
 |
|
@ PGWARE
Thanks a lot for your very long and interesting informations. I read it not before my last posting. Now I understand the nesessity of the complicated IsAdmin function.
From now on i will start programming in the way you described. Most of my little tools I wrote for my own purposes and most of them worked on other computers as well, but a lot of them use for example global temp-dir etc.
On my own computers I never install any pogram to the system partition and i'm angry about ever program that writes to C:\documents and settings\...\Application data\... In my opinion on the system partition has nothing a business that not belongs to the system itself.
but if i make apps that should run on any computer I need to obtain the global program files dir if i want that any user can access the program and so for the simplest app i need elevation. I can understand the importance of UAC but it means a lot more work for me and a completely new thinking of what belongs to were on disk.
I hope you understand - sorry for my strange english - and thanks again
Edit: Oh I see you posted already again ...
It is clear to me now - but another question: what about the 32bit dlls on 64 bit systems? Do i not have to care about that? |
|
| Back to top |
|
 |
PGWARE
Web Host
Joined: 29 Dec 2001
Posts: 1567
|
| Posted: Wed Feb 24, 2010 1:18 am Post subject: |
|
|
I ran your bsAdmin function, I compiled the exe and included a manifest which requires an administrator to run the exe. It seems to work really well; it looks like the user impersonation does in fact load the user settings/registry for the admin user/pass that is supplied when running elevated.
Windows 7 (UAC ON):
Logged in as Admin: reports logged in as admin
Logged in as standard user: reports logged in as admin (prompted with uac)
Windows 7 (UAC OFF):
Logged in as Admin: reports loged in as admin
Logged in as standard user: reports logged in as admin (even with uac off the uac elevation and password prompts still appear - it appears windows does not allow limited user to run without uac prompts)
Windows Vista (UAC ON):
Logged in as Admin: reports logged in as admin
Logged in as standard user: reports logged in as admin (prompted with uac)
Windows Vista (UAC OFF):
Logged in as Admin: reports logged in as admin
Logged in as standard user: reports no admin - no uac prompt or elevation appears at all
* It appears Microsoft changed the behavior in Windows 7, even if uac is turned off by the admin, prompts still appear for limited users. Probably just because of this reason in Windows Vista where no prompt is shown to allow elevation the program does not run correctly for limited users because privileges arent allowed. *
Windows XP:
Logged in as Admin: reports logged in as admin
Logged in as standard user: reports logged in as admin (when you do runas)
Definately a very nice and much easier (less breakable too) solution that you have found here! |
|
| Back to top |
|
|
PGWARE
Web Host
Joined: 29 Dec 2001
Posts: 1567
|
| Posted: Wed Feb 24, 2010 2:05 am Post subject: |
|
|
vdsalchemist - your code works great in xp, vista and 7. But the runas command has no effect on Windows Vista/7. You should change the code a bit for Windows XP, if you arent an admin it should prompt to runas, you currently have it the other way around where if you are an admin it asks to run as an admin  |
|
| Back to top |
|
|
bornsoft
Contributor
Joined: 19 Feb 2009
Posts: 113
Location: Germany
|
| Posted: Wed Feb 24, 2010 2:14 am Post subject: |
|
|
I'm very happy, that it works on 7.
What you found out with turned off UAC on a limited account is because you included "RequireAdministrator" i think.
The behavior under Vista is like I wanted to do it - so one can tell the user that it makes no sense to continue and abort the planned action.
It would be interesting for me what happens if the function is used again. I mean you elevate for a single action and after that does the groupmembership for admins remain in registry or is it canceled? |
|
| Back to top |
|
|
PGWARE
Web Host
Joined: 29 Dec 2001
Posts: 1567
|
| Posted: Wed Feb 24, 2010 2:15 am Post subject: |
|
|
| Quote: |
On my own computers I never install any pogram to the system partition and i'm angry about ever program that writes to C:\documents and settings\...\Application data\... In my opinion on the system partition has nothing a business that not belongs to the system itself.
|
The application data/users folder is where you should write user settings if not using the registry. You arent supposed to store user data in c:\program files\ as non-elevated exe's cant access and write to program files anymore. They did this because if c:\program files\ was writable by any program without elevation then any .exe could be replaced and ran - something malware does. So they decided to separate out where user data should be written. In fact this has always been the case but no one followed the guidelines and just wrote to c:\program files\ anyway. Check in Windows XP as a limited user account, it not possible to write settings or files to c:\program files\ without being an admin user. Since all accounts run in a limited mode in Vista/7 it became more apparent.
Check that vista post guidelines I mentioned in my earlier reply I showed you can set an ACL permission on files/directories/registry to write to them without having to elevate. You should only do this if you know the implications security-wise. For example you can safely set the ACL to everyone-modify to your own file in c:\program files\my program\program.ini and read/write settings to that with a non-elevated exe. But if a guest user logged into your computer they could access that program.ini file and delete or modify it since it has the everyone-modify permission. Obviously you dont want to set ACL's to entire directories full of exe files since anyone could replace those exe's with harmful ones.
Regarding where to place system dll's on 64-bit systems. You put 32-bit dlls inside of c:\windows\syswow64, and 64-bit dll's inside of c:\windows\system32 |
|
| Back to top |
|
|
PGWARE
Web Host
Joined: 29 Dec 2001
Posts: 1567
|
| Posted: Wed Feb 24, 2010 2:18 am Post subject: |
|
|
bornsoft once you elevate the exe it appears you have access to that admins account settings/registry hive.
Other programs running on your computer still have access only to the logged in user registry/hive.
Calling the bsAdmin function multiple times has no real effect - it just keeps checking the same registry value. When you run the program elevated you are impersonating the admin user and have access to his registry (from your program) until you close your program.
Also yes in Vista - limited user account with uac off; simply run the bsAdmin function and tell the user to log into an admin account. Your function works correctly.
I did use requireAdministrator in the manifest.
Last edited by PGWARE on Wed Feb 24, 2010 2:33 am; edited 2 times in total |
|
| Back to top |
|
|
vdsalchemist
Admin Team
Joined: 23 Oct 2001
Posts: 1448
Location: Florida, USA
|
| Posted: Wed Feb 24, 2010 2:18 am Post subject: |
|
|
| PGWARE wrote: | | vdsalchemist - your code works great in xp, vista and 7. But the runas command has no effect on Windows Vista/7. You should change the code a bit for Windows XP, if you arent an admin it should prompt to runas, you currently have it the other way around where if you are an admin it asks to run as an admin |
Yeah I seen that and will change it so as not to confuse people however Note that if you have the code as I wrote it you would not need a manifest in Vista or 7. This is good for those utilities that have both Admin functionality and non-Admin functionality but this would be for a very limited use case. Such as when you are writing a installer or you have a user application that installs advanced features such as a service or special driver after the main program has been installed. Also if you are building a program launcher. I could think of more but I think you get the idea. To be honest I threw in the runas just to show that you don't need any fancy script or API to make a VDS EXE run as Admin. This is only a demo and you should use your best judgment. IMHO I prefer it if the user has to type the admin password like you do with Mac and Linux/Unix. I have noticed that once a user figures out that they just need to click the allow they get into the habit and do what they can to remove the prompt to get the program to run. If Windows required the user to type a password then it may make them think twice before hitting the allow button. 
_________________
Home of
Give VDS a new purpose!
 |
|
| Back to top |
|
|
PGWARE
Web Host
Joined: 29 Dec 2001
Posts: 1567
|
| Posted: Wed Feb 24, 2010 2:23 am Post subject: |
|
|
They may eventually require entering a password even when you are logged in as an admin. I believe they didnt initially because most people already hate UAC and they are transitioning users over to this experience, requiring a password would make people hate it even more. Once more and more developers start making their apps run under a limited user account and dont require admin privileges then using a uac with required password shouldnt be an issue as you will see less and less of these dialogs.
You are right there was an article on microsofts website about uac fatigue that what may happen is users just continue past the uac prompt and click YES. They noted that developers should attempt to not elevate unless really needed. What happened was some developers found it easier to throw a manifest into the .exe with requireAdministrator for elevation (I did this too) as it was an 'easy solution' to get compatible but it also causes problems. Allowing the developer to include a string that is displayed of what changes and why the elevation is required would have been nice as well.
Last edited by PGWARE on Wed Feb 24, 2010 2:44 am; edited 1 time in total |
|
| Back to top |
|
|
vdsalchemist
Admin Team
Joined: 23 Oct 2001
Posts: 1448
Location: Florida, USA
|
| Posted: Wed Feb 24, 2010 2:43 am Post subject: |
|
|
| PGWARE wrote: | | They may eventually require entering a password even when you are logged in as an admin. I believe they didnt initially because most people already hate UAC and they are transitioning users over to this experience, requiring a password would make people hate it even more. Once more and more developers start making their apps run under a limited user account and dont require admin privileges then using a uac with required password shouldnt be an issue as you will see less and less of these dialogs. |
Yes I agree... I have adopted the habit of making all my programs self contained in a single folder and I don't even save configuration data in the registry. Most of my programs are utilities for Servers. My programs have to have the smallest possible impact to the environment so they don't do anything that cannot be undone just by removing the folder and it's contents. To me this is the best course of action unless you use a installer and even with that I would suggest that you keep it to single folders and minimize the use of the registry as much as possible.
_________________
Home of
Give VDS a new purpose!
|
|
| Back to top |
|
|
PGWARE
Web Host
Joined: 29 Dec 2001
Posts: 1567
|
| Posted: Wed Feb 24, 2010 2:49 am Post subject: |
|
|
vdsalchemist are you storing settings in the users data folder then?
You can modify the ACL for registry keys (for example hkey_local\software\vds) but obviously you'd have to use an installer or require elevation to do the ACL writes. Then you can run your program non elevated and write to the registry all day long. It shouldnt have any effect system wide provided your application doesnt reak havok on the system if registry values were changed by any logged in user. I don't know Microsoft's take on using ACL in this manner but they probably wouldnt mind provide you arent modifying the entire hkey_local or c:\program files\ permissions.
I prefer using the registry instead of writing files to the disk. Some of my software needs to read/write updated data constantly. I've tried using configuration files into the all users directory and have had complaints with users that have SSD drives installed (constant reads) or other backup software installed (writesw) which did not like the constant read and writes to the files but the registry wasnt a problem.
Last edited by PGWARE on Wed Feb 24, 2010 3:46 am; edited 1 time in total |
|
| Back to top |
|
|
Aslan
Valued Contributor
Joined: 31 May 2001
Posts: 589
Location: Memphis, TN USA
|
| Posted: Wed Feb 24, 2010 3:18 am Post subject: |
|
|
| vdsalchemist wrote: | Bornsoft,
I have seen posts that the IsNTAdmin function does not work under Vista and Windows 7. However that does not mean that it does not you could try it. |
I use IsNTAdmin with Vista and Win 7 at work and haven't had any problems with it so far. (Knock on wood) |
|
| Back to top |
|
|
bornsoft
Contributor
Joined: 19 Feb 2009
Posts: 113
Location: Germany
|
| Posted: Wed Feb 24, 2010 3:32 am Post subject: |
|
|
back again.
I've combined my function with vdsalchemist's RunAsAdmin command.
On xp it works perfect, could you test it on Vista/7 please?
Please compile it and test it with no execution level specified. Thanks.
I know, i should set up win7 myself but i'm afraid that i need faster hardware first :-/
Edit: You need a file named test.txt in the same folder as the compiled exe.
How can I prevent line-breaks in code-tags in the forum?
| Code: |
#DEFINE Function,bsAdminCheck
#DEFINE Command,RunAsAdmin
%%CmdLine = @CmdLine()
if @equal(@Pos(runasadmin,%%CmdLine),0)
if @bsAdminCheck()
info Let's try to copy [ @path(%0)test.txt ] to [ C:\test.txt ] now.@tab()
goto start
else
if @ask(You are not an Administrator.@CR()Would you like to run this program as administrator?@tab())
RunAsAdmin %0
stop
else
info Exit.
stop
end
end
end
:Start
file copy,@path(%0)test.txt,c:\test.txt
if @ok()
info "Yeah, I did it."@tab()
else
info "Sorry, I faild."@tab()
end
stop
:RunAsAdmin
shell runas,@chr(34)%1@chr(34),runasadmin,@chr(34)@Path(%1)@chr(34)
exit
:bsAdminCheck
# Constant security identifier for Admin group
%S = "S-1-5-32-544"
%K = "Software\Microsoft\Windows\CurrentVersion\Group Policy\GroupMembership"
%L = @new(list)
list RegVals,%L,Curuser,%K
repeat
%n = @next(%L)
if %n
if @equal(@regread(Curuser,%K,%n),%S)
%R = 1
end
end
until %R @not(%n)
list close,%L
exit %R
|
|
|
| Back to top |
|
|
PGWARE
Web Host
Joined: 29 Dec 2001
Posts: 1567
|
| Posted: Wed Feb 24, 2010 3:43 am Post subject: |
|
|
Runas does not work on Windows 7/Vista. You need to use requireAdministrator in a manifest.
Also check this thread: http://forum.vdsworld.com/viewtopic.php?t=4954
It talks about 64-bit and how to get the SysWow64 directory to copy files into. Also includes a function to determine if running in windows 32-bit or 64-bit. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
@vdsworld