| View previous topic :: View next topic |
| Author |
Message |
cnodnarb
Professional Member
Joined: 11 Sep 2002
Posts: 766
Location: Eastman, GA
|
 Posted: Sun May 08, 2011 7:54 pm Post subject: Windows Vista, 7 help with best practice - SOLVED |
 |
|
I can't stand some of the new things in Windows 7. I'm having trouble adjusting.
I need to be able to do simple things, like rename files etc.
Are we better off installing to the root directory instead of program files (x86)? Seems less restrictive.
Perhaps always calling runasadmin (this has to be some kind of bizzare loophole btw)
| Code: |
if @null(%1)
shell runas,@chr(34)%0@chr(34),runasadmin @chr(34)I am administrator@chr(34)
stop
end
info %2
|
In your opinion, what is the best way to get slightly elevated privilege (ability to rename files, use ini files, etc) to your own install folder without doing anything too drastic?
Last edited by cnodnarb on Mon May 09, 2011 12:05 am; edited 2 times in total |
|
| Back to top |
|
 |
PGWARE
Web Host
Joined: 29 Dec 2001
Posts: 1565
|
| Posted: Sun May 08, 2011 9:32 pm Post subject: |
|
|
Why would you need to rename files in your program files install directory?
If you need to build files you should put them into the documents folder of the user, preferably in your own folder so users know that folder belongs to your program and can delete it if they choose.
If your program needs the ability to run as an admin you should compile the exe with requireadmin elevation privileges so a UAC prompt is displayed - this while you may consider an annoyance allows users to know this program will do something possibly system wide and can choose to run it or not.
If your program is intended to be only run on your computer and not for general public then yes install it to any directory other than the program files directory. Be also mindful accessing the registry at hkey_local requires admin privileges to write to it.
A way to bypass these things is when installing the files to program files or the registry you can set an ACL to the specific files and registry keys you want to modify using a non-elevated process/exe, setting the acl to everyone-modify even gives guest users on the computer access to modify those files and registry entries - so be careful with this. So for instance if you give the everyone-modify ACL access on your c:\program files(x86)\my program\program.exe then a guest user could login to the system and replace program.exe with a trojan - thus opening the door to a security violation on the entire system when someone thought your software was secure and didnt expect program.exe to be malicous. So be careful with ACL permissions. Most installers will allow you to write ACL permissions, I use Innosetup and it allow it. |
|
| Back to top |
|
|
cnodnarb
Professional Member
Joined: 11 Sep 2002
Posts: 766
Location: Eastman, GA
|
| Posted: Sun May 08, 2011 10:06 pm Post subject: |
|
|
Curiouser and curiouser....
When I use my runasadmin from a non-restricted directory, it doesn't prompt the user for permission. When I run it from syswow64 it prompts the user...
Same thing with program files...prompts user.
I would still like to know how to set up a manifest to do this instead of having to do it programmatically 
I'm all set for now though. Thanks! |
|
| Back to top |
|
|
LiquidCode
Moderator Team
Joined: 05 Dec 2000
Posts: 1753
Location: Space and Time
|
| Posted: Sun May 08, 2011 10:38 pm Post subject: |
|
|
With that, I am using windows XP. Does anyone run Save-It on Windows 7? Does it work ok? I am using VDS 5 and do not have the option of compiling as admin.
_________________
Chris
Http://theblindhouse.com |
|
| Back to top |
|
|
cnodnarb
Professional Member
Joined: 11 Sep 2002
Posts: 766
Location: Eastman, GA
|
| Posted: Sun May 08, 2011 10:39 pm Post subject: |
|
|
I bet that's why Chrome installed here: C:\Users\Brandon\AppData\Local\Google\Chrome\Application
How do we get our applications to do that? |
|
| Back to top |
|
|
cnodnarb
Professional Member
Joined: 11 Sep 2002
Posts: 766
Location: Eastman, GA
|
| Posted: Sun May 08, 2011 10:40 pm Post subject: |
|
|
RE liquidcode: I'm on Windows 7, no fears works like a champ. Updater prompts with admin privileges and works fine.
Last edited by cnodnarb on Sun May 08, 2011 10:41 pm; edited 1 time in total |
|
| Back to top |
|
|
LiquidCode
Moderator Team
Joined: 05 Dec 2000
Posts: 1753
Location: Space and Time
|
| Posted: Sun May 08, 2011 10:40 pm Post subject: |
|
|
Try using @windir(AppData) 
_________________
Chris
Http://theblindhouse.com |
|
| Back to top |
|
|
cnodnarb
Professional Member
Joined: 11 Sep 2002
Posts: 766
Location: Eastman, GA
|
| Posted: Sun May 08, 2011 10:46 pm Post subject: |
|
|
| Ah...I think I know why no prompt on certain folders. If the user is an administrator and they created the folder themselves (they own it) and the application request administrator rights there is no UAC prompt. A rare occurance that was confusing me. |
|
| Back to top |
|
|
cnodnarb
Professional Member
Joined: 11 Sep 2002
Posts: 766
Location: Eastman, GA
|
| Posted: Sun May 08, 2011 10:50 pm Post subject: |
|
|
AHA! If your in the users appdata folder you can do several simple task, rename files, use config files without difficulty etc WITHOUT being an administrator.
This is not possible when installed to Program Files(x86).
If it's good enough for google, adobe etc. it's good enough for me. I'm targeting that. |
|
| Back to top |
|
|
cnodnarb
Professional Member
Joined: 11 Sep 2002
Posts: 766
Location: Eastman, GA
|
| Posted: Sun May 08, 2011 11:00 pm Post subject: |
|
|
| Quote: | | If you need to build files you should put them into the documents folder of the user, preferably in your own folder so users know that folder belongs to your program and can delete it if they choose. |
I feel this is bunk. There's plenty of times I can think of that files should be stored in the application folder. Liquidcode's updater that modifies the directory is just one example. I have a calendar program I use that writes files to it's own app folder. It was common practice that worked for over a decade, and hell linux and other OS's practically run on the philosophy.
Another is http://forum.vdsworld.com/viewtopic.php?t=5187 where I would like to see people start getting credit for externals they develop in VDS.
Giving the user the option to accidently KILL your program data isn't really an option for me.
[EDIT]
Ultimately though, this problem is solved. When installed to the appdata folder the program does not run suspected of malicious acts (doesn't have to run as admin prompting UAC) and can also modify it's own directory (delete files, write to files etc.)
I would still LOVE to learn more about file manifest.
[/EDIT] |
|
| Back to top |
|
|
cnodnarb
Professional Member
Joined: 11 Sep 2002
Posts: 766
Location: Eastman, GA
|
| Posted: Mon May 09, 2011 12:04 am Post subject: |
|
|
I'm a bull sometimes LoL! Wave a cape and I attack! I like this suggestion, actually this is probably perfect. Hardly noticed it though my first read through ;p
| Quote: | | A way to bypass these things is when installing the files to program files or the registry you can set an ACL to the specific files and registry keys you want to modify using a non-elevated process/exe, setting the acl to everyone-modify even gives guest users on the computer access to modify those files and registry entries - so be careful with this. So for instance if you give the everyone-modify ACL access on your c:\program files(x86)\my program\program.exe then a guest user could login to the system and replace program.exe with a trojan - thus opening the door to a security violation on the entire system when someone thought your software was secure and didnt expect program.exe to be malicous. So be careful with ACL permissions. Most installers will allow you to write ACL permissions, I use Innosetup and it allow it. |
|
|
| Back to top |
|
|
PGWARE
Web Host
Joined: 29 Dec 2001
Posts: 1565
|
| Posted: Mon May 09, 2011 4:42 am Post subject: |
|
|
| Quote: | | I feel this is bunk. There's plenty of times I can think of that files should be stored in the application folder. Liquidcode's updater that modifies the directory is just one example. I have a calendar program I use that writes files to it's own app folder. It was common practice that worked for over a decade, and hell linux and other OS's practically run on the philosophy. |
Just because people were doing things wrong for the past 10 years doesnt mean it should be continued, Microsoft documented long ago back when XP came out how software should work and writing to program files was definatley a no-no - devs decided not to listen and have paid for it when vista/7 came out. This change started with Vista, and it intentionally broke many programs and developers had to rewrite their code to deal with this. It's a security issue, and many programs on other OS's require admin rights to run or modify system level files. THe program files directory, windows directory (and all subdirs under these) require admin privileges, as does the windows registry with hkey_local.
Theres a forum post here on this dated back from almost 3 years ago when Vista came out and these changes were made and how to rewrite your software to account for it. Most of these changes do not take more than a couple minutes/hours to fix in your software.
Note that setting ACL's should be done with care, you dont want to modify someones computer settings and open it up to vunerabilities. Work within Windows Vista/7 guidelines as best as possible. We may not like the security changes Microsoft now mandates but that doesnt mean we should modify end users computers and put their machines in a security vunerable state. If you do set an acl - limit it only to your directory, preferable only to single files and never to an .exe, .dll or any executable as those can be swapped/replaced by anyone logged into the machine (even guests) and open that computer up to vunerabilities. The same for registry - limit it only to specific keys not entire groups of registry hives or groups.
-----
Here are the two manifests you can use, either to run as an admin, or as invoker. the trustinfo section is what is really new, the other sections deal with using the new windows common controls v6 and declaring your app is dpi aware; you don't have to include these two portions if you don't want.
Run as admin:
Use this in your manifest to have your exe prompt for a UAC (run elevated)
| Code: |
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<assemblyIdentity
type="win32"
name="YourCompany.YourProduct"
version="1.0.0.0"
processorArchitecture="x86"
/>
<description>Your Product</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="x86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"
/>
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
|
Run as invoked:
Run your program as invoked, if someone right clicks and runs as admin it will run elevated, if its just double clicked to run it will run as a standard user.
| Code: |
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<assemblyIdentity
type="win32"
name="YourCompany.YourProduct"
version="1.0.0.0"
processorArchitecture="x86"
/>
<description>Your Product</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="x86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"
/>
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
|
- change YourCompany.YourProduct to someting like: VDSWORLD.MyEXE
- you can change the version number below it as well.
- you can change the description as well. |
|
| Back to top |
|
|
cnodnarb
Professional Member
Joined: 11 Sep 2002
Posts: 766
Location: Eastman, GA
|
| Posted: Mon May 09, 2011 5:36 am Post subject: |
|
|
You rock! Thank you for the manifest information!
I was just frustrated earlier that I can't rename DLL's to EXE's and back again, because all the other factors fell into place except for mandated restrictions.
1. DLL displayed property page
2. EXE could be loaded to memory, and renamed back to DLL while still in memory, meaning only named exe for about 1ms.
Ultimately though this was 'smoke and mirrors' anyway, and the new vdsx ideal on that thread works out better and is more honest (and now we are compliant with modern coding standards).
I am happy for the manifest information! I didn't feel right calling my app from my app to run as administrator. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
@vdsworld