-
Nov 23rd, 2017, 09:47 AM
#1
Thread Starter
Fanatic Member
User Access Control
Is it possible to prevent the User Access Control's warning 'Do you wish to allow this programme to make changes etc' every time my programme starts?
I run a manifest resource, but wonder if that is enough!
Resource:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="3.0.0.0"
processorArchitecture="X86"
name="Music Master"
type="win32"
/>
<description>Library/Player</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
<!-- Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!-- Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!-- Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!-- Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
</application>
</compatibility>
<!-- Identify the application security requirements: Vista and above -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="highestAvailable"
uiAccess="false"
/>
</requestedPrivileges>
</security>
</trustInfo>
<!-- Identify advanced options: Vista and above -->
<asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<autoElevate>true</autoElevate>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
-
Nov 23rd, 2017, 10:25 AM
#2
Re: User Access Control
No.
You seem to be missing the point of UAC entirely: "Do not allow programs to run with elevated rights without manual approval by the user. If the user is not a member of Administrators, allow over-the-shoulder elevation by accepting admin credentials for another user."
Things have worked this way for over a decade now.
The correct solution is to rewrite your programs to run properly in Standard User mode. For most programs only the installation process should require elevation, and if you need administration rights for some functions those should be marked with the UAC icon to warn users that an elevation prompt will be raised.
-
Nov 23rd, 2017, 10:46 AM
#3
Re: User Access Control
Couple things
1. AutoElevate. You are asking to "run elevated". Similar to right clicking app and "run as administrator". At least that's how I interpret that setting.
2. Trust Info highestAvailable.
- Standard User. No change, runs as standard user
- Any others (non-admins). Depends on the O/S as I understand it. Prior to Win10, you may not have gotten a prompt. Win10 will likely get your user prompted depending on what user-groups they belong to.
Recommendation: Don't AutoElevate and use asInvoker. If your app is a standard application that does not need to modify system/protected files/folder and/or registry items, there is no need for any user to run your app with other than "standard user" permissions.
-
Nov 23rd, 2017, 10:53 AM
#4
Re: User Access Control
The <autoElevate/> section is ignored unless your program meets a number of restrictions. These are completely impractical for programs that are not part of Windows.
-
Nov 23rd, 2017, 10:56 AM
#5
Re: User Access Control
Originally Posted by dilettante
The <autoElevate/> section is ignored unless your program meets a number of restrictions. These are completely impractical for programs that are not part of Windows.
May depend on the O/S: Win7 and below? Otherwise I've seen comments regarding that it may apply only to digitally signed applications. This one is a gray area for me. There's probably a definitive link on its usage, but I haven't looked hard for it
https://technet.microsoft.com/en-us/...09.07.uac.aspx
@Steve. Here is a good link regarding the Trust Info settings
https://msdn.microsoft.com/en-us/library/bb756929.aspx
-
Nov 23rd, 2017, 11:00 AM
#6
Re: User Access Control
Such applications must be within a very few directories on the system drive. They also must be signed by "the Windows publisher" which is different from other Microsoft certificates. There are additional requirements as well but most of those are not documented.
-
Nov 23rd, 2017, 03:46 PM
#7
Thread Starter
Fanatic Member
Re: User Access Control
Thank you both for your comments. I have gone back to my original res file, which is shown below, everything works fine (no UAC prompt) except writes to Programdata/My Programme/Files no longer work. My programe shows the progressbar and appears to write the data, but nothing is written. Any Ideas ? Current res file;
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="2.7.0.1"
processorArchitecture="X86"
name="Music Master Producer"
type="win32"
/>
<description>Automated Playout system with true 'Level' checking for Player Start. </description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<!-- Identify the application security requirements: Vista and above -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"
/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
-
Nov 23rd, 2017, 03:54 PM
#8
Thread Starter
Fanatic Member
Re: User Access Control
Thought I should add this. Remember this works fine elevated.
Code:
Public Function UnicodeWriteAPI(ByVal sFileName As String, ByVal sText As String) As Boolean
Dim lpFileInfo As OFSTRUCT
Dim lpOverlapped As OVERLAPPED
Dim szPathName As String * OFS_MAXPATHNAME
Dim hFile As Long
Dim lResult As Long
Dim lLengthRet As Long
szPathName = sFileName
With lpFileInfo
.cBytes = Len(lpFileInfo)
.fFixedDisk = 1
.szPathName = szPathName
End With
hFile = OpenFile(sFileName, lpFileInfo, OF_CREATE)
If (hFile) Then
lResult = WriteFile(hFile, ByVal StrPtr(sText), LenB(sText), lLengthRet, lpOverlapped)
UnicodeWriteAPI = lResult <> 0
CloseHandle (hFile)
End If
End Function
-
Nov 23rd, 2017, 05:11 PM
#9
Re: User Access Control
Any ideas? One thing in your manifest may be off. The TrustInfo entry is using urn:schemas-microsoft-com:asm.v2 and probably should be urn:schemas-microsoft-com:asm.v3. Wondering if making that change will have any effect? Also, there are no entries for supported O/S. Might want to at least select Vista?
Edited: Curious? That manifest come from my Manifest Creator utility? If so, I've since stopped defaulting for v2 and opt for v3 within the latest update/version (my signature below).
Last edited by LaVolpe; Nov 23rd, 2017 at 05:14 PM.
-
Nov 23rd, 2017, 08:31 PM
#10
Re: User Access Control
Originally Posted by LaVolpe
Also, there are no entries for supported O/S. Might want to at least select Vista?
I'm pretty sure that isn't necessary, the Vista entry is pretty much a no-op added only for cosmetic reasons. As for the rest, those are for version-lie appcompat. Unless your program was specifically written to be compatible with OSs beyond Vista they are not needed either. For the most part none of them hurt anything... unless your program expects and requires ancient behavior from Windows APIs.
Far too many people write programs that pretend that Win9x is still a thing and they are not running on NT. They limped along on Windows XP by making every user a member of either the Administrators or Power Users groups. Those days are long gone.
-
Nov 23rd, 2017, 06:21 PM
#11
Thread Starter
Fanatic Member
Re: User Access Control
Thanks for the info. I re-downloaded your Manifest Creator and tried the following;
Code:
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity name="Music Master" version="1.0.0.0" type="win32" processorArchitecture="x86"/>
<dependency>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Windows.Common-Controls" version="6.0.0.0" type="win32" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"/>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Windows.GdiPlus" version="1.1.0.0" type="win32" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
</application>
</compatibility>
</assembly>
With the above function it still will not write to the ssfCommonAppData (H23) folder without elevation. I did try a simple open - write - close and that worked fine but is not Unicode.
-
Nov 23rd, 2017, 08:43 PM
#12
Re: User Access Control
Originally Posted by Steve Grant
I did try a simple open - write - close and that worked fine but is not Unicode.
No, it wouldn't write Unicode. But it still isn't magical, you probably just thought it was. That has the same security issues as writing the other way using API calls.
-
Nov 23rd, 2017, 07:09 PM
#13
Re: User Access Control
Likely permissions. Here's a quote from another site (should be verified for accuracy)
The snag is your installer should create the app's subfolder there and set appropriate security on it to permit required access (often you want Full Control for Users). By default, files and folders are created there with owner access.
And a link from Karl Peterson, worth looking over from time to time
-
Nov 23rd, 2017, 08:40 PM
#14
Re: User Access Control
Don't dump data into ssfCOMMONAPPDATA any more than you'd install programs under ssfPROGRAMFILES. Instead your installer should create a strongly-named subfolder there and set the desired security on it. Normally these subfolders are named {companyname}\{appname} to avoid colliding with other software.
The security on ssfCOMMONAPPDATA has the CREATOR OWNER pseudo-account access control entry in its ACL and this is inherited by objects (folders and files) created within it. If you want all users to have read/write access (and maybe create, delete, etc.) your installer should set the desired security on each filesystem object (often just an app-related folder).
Last edited by dilettante; Nov 23rd, 2017 at 09:04 PM.
-
Nov 23rd, 2017, 09:07 PM
#15
Re: User Access Control
If you don't want to deal with this in an installer you could also detect your program's "first run" and do it from within that.
See ProgramData for common files which has a description and sample code. The thread runs on a for a while, identifying and fixing some localization issues so you'll probably want the version 4 attached to post #24.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|