locked
Elevate via code in Vista? RRS feed

  • Question

  • We have an application that is an add-on to another application.  While the child app is being installed, it must edit some files belonging to the parent.  We wrote an .exe in VB 2005 that performs this action.  It has been in production on XP for some months and works fine.  It will not, of course, run on Vista with UAC on.

    Is there an SDK function that provides programatic elevation?  I've searched MSDN but can't find any such function.

    Help.
    Tuesday, February 5, 2008 2:34 PM

All replies

  • Does your installer elevate?  Do you install to a machine-wide location like Program Files?  If so, you should be able to modify the file during installation for your app.

    Tuesday, February 5, 2008 7:25 PM
  • We are using the WiX installer.  It generates a standard MSI file.

    But, this program is a separate EXE that is invoked by the installer.  The problem is the fact that the file belongs to the parent program.  It is in a directory rooted on C:\ProgramData.  It was written when the parent program was installed.

    We have no control over the parent program.  It belongs to someone else.

    Since I posted the original message in this thread, we have found that the program also modifies these files during normal execution.  (We did not write the program.)  So, either we leave UAC off all the time, or we find a way to elevate a program during execution.

    Dick.
    Tuesday, February 5, 2008 8:46 PM
  • UAC probably has nothing to do with your problem, in that case.  If the file is in use, and isn't opened with file_share_write, you won't be able to edit it until the handle to the file is closed.

     

    Depending on the ACL on the file, you may be able to edit that file from a deferred action running as the user, rather than one running as the system.  If it isn't ACL'd for write by Users or something to that effect, you may need your exe action to run elevated. I'm not sure how you do that in WiX.

    Wednesday, February 6, 2008 1:09 AM
  • The program works with UAC turned off.  It does not work with UAC turned on.

    The file is not in use when our program is trying to modify it.  The program that owns it is not running.

    Dick.

    Wednesday, February 6, 2008 2:33 AM
  • Since you're using Windows Installer, it should be possible to configure the permissions on the directory using the LockPermissions table. The appropriate WiX element is detailed here. Since this is a subdirectory of ProgramData, it shouldn't cause any obvious security issues or affect Logo compatability if that's important.

     

    Wednesday, February 6, 2008 9:39 AM
  •  

    Since you're using Windows Installer, it should be possible to configure the permissions on the directory using the LockPermissions table. The appropriate WiX element is detailed here. Since this is a subdirectory of ProgramData, it shouldn't cause any obvious security issues or affect Logo compatability if that's important.
    Wednesday, February 6, 2008 10:36 AM
  • It works with UAC off;  it doesn't with UAC on.  The parent program is not running (either during installation or during later operations) when our program tries to edit the file.

    The ACL includes both SYSTEM and Users.

    The only solution we can see (other than running with UAC off) is to be able to elevate individual programs.  We have tried ShellExecute(runas), but that doesn't work, either.


    Wednesday, February 6, 2008 2:57 PM
  •  

    Since you're using Windows Installer, it should be possible to configure the permissions on the directory using the LockPermissions table. The appropriate WiX element is detailed here. Since this is a subdirectory of ProgramData, it shouldn't cause any obvious security issues or affect Logo compatability if that's important.
    Wednesday, February 6, 2008 4:28 PM
  • We can't change the ACL.  The directory belongs to the parent program.
    Wednesday, February 6, 2008 5:20 PM
  •  

    What is the ACL?

    Wednesday, February 6, 2008 8:35 PM
  • ACLs:
     - file1.ini:  SYSTEM, Administrators, Users.
     - dir1.ini:  CREATOR OWNER, SYSTEM, Administrators, Users. (contains file1.ini).
     - file2.ini:  <admin user name>, SYSTEM, Administrators, Users.
     - dir2.ini:  <admin user name>, CREATOR OWNER, SYSTEM, Administrators, Users. (contains file2.ini).

    Note that we have never gotten beyond the attempt to edit file1.ini, so have no idea if file2.ini is editable.


    Thursday, February 7, 2008 3:37 PM
  • And what permissions are associated with those entries?

    Friday, February 8, 2008 1:27 AM
  • Hi all,

    Here is my guide to UAC:
    http://social.msdn.microsoft.com/Forums/en-US/windowssecurity/thread/dd400cb9-d5fc-41b2-ad9d-6b91ce88c766

    Have a nice day....

    Best regards,
    Fisnik
    Coder24.com
    • Proposed as answer by Fisnik Hasani Saturday, October 10, 2009 8:03 AM
    Sunday, October 4, 2009 3:19 PM
  • Hello Dick:

    Is this issue solved? How is the situation on your side?
    Please provide some information, thanks!

    Have a nice day...

    Best regards,
    Fisnik
    Coder24.com
    Friday, October 9, 2009 7:39 PM
  • Hello Dick:

    Is this issue solved? How is the situation on your side?
    Please provide some information, thanks!

    Have a nice day...

    Best regards,
    Fisnik
    Coder24.com
    Friday, November 13, 2009 8:35 PM
  • Hello Dick:

    Is this issue solved? How is the situation on your side?
    Please provide some information, thanks!

    Have a nice day...

    Best regards,
    Fisnik
    Coder24.com
    Thursday, November 26, 2009 10:17 AM
  • Hi again:

    How is the situation on your side?
    Is this thread solved?

    Please tell me!

    Have a nice day...

    Best regards,
    Fisnik
    Coder24.com
    Sunday, December 27, 2009 9:46 AM
  • Hi again:

    How is the situation on your side?
    Is this thread solved?

    Please tell me!

    Have a nice day...

    Best regards,
    Fisnik

    Coder24.com
    Saturday, January 2, 2010 2:54 PM