none
Writing to the VFS in User Context with the CMD.EXE and other commands RRS feed

  • Question

  • Hello All,

    I have been working on a sequence for days now which could be fixed easily if the virtual CMD shell worked like a regular one.

    My App is strange when sequenced as it deletes a file from the VFS when launching. It launches fine on first run after deleting the file. I cant deny it access as it then wont launch. I have set a script to CACLS part of the program files area so it can do this.

    Write permissions on the sequencer tab are not enough and so I had to do this.

    I'm using 5.1 and Windows 10.

    What I needed was a launcher that checks to see if calendar.dll exists, on launch. if it does (first launch), exist and continue,

    if it doesn't copy bak.dll (a copy of calendar.dll) to calendar.dll, launch the exe and exit.

    I wrote a console based launcher in .NET and added it to the sequence along with bak.dll.

    It should all be so simple yet it's not. the CMD/C Copy command doesn't work in the Virtual environment complaining about path not found. It works fine in a regular Shell session.

    I have tried renaming bak.dll to calendar.dll but that says access denied.

    I can rename bak.dll to bak.dsd (made that extension up) and it's all good.

    There appears to be limitations on what you can do in the Shell Virtual session.

    Anyone have any experience of this, or can suggest another alternative?

    So close.. to getting it working and yet so far.

    Thanks, Bryn

    Wednesday, July 3, 2019 10:44 AM

Answers

  • Hi, like the solution suggest, this is COW protected file (.dll) and can't be modified inside the VE without hacking APPV folder rights (not recommended).
    My quickfix would be merging the virtual directory where calendar.dll resides  with local filesystem and then script the folder creation into base os during add package event or on publishing  (mkdir c:\xxx) and set correct permission on the dir with icalcs on the next step.
    Then Delete calendar.dll (as i understand that's the file that's being modified) from your package and copy it into your script folder in the package.
    Then make a script in your package that copy this file into the local folder during add or publishing of package after the first script has created it and put the correct icacls rights on it. 

    Then your application should see the folder and dll with the correct file/folder permissions and be able to modify it. Remember to put a delete command on file/folder on package removal.
    I do this all the time with old sh*tty sw packages.

    From a security perspective it may be better to redirect the local folder with a junctionpoint to a folder share where you can isolate rights more easily with AD groups and without compromising system security.

    And remember this solution may give you some problems is if there is several versions of the same program on the same system at the same time, and they all need access to different version of the file. Then you need to modify installdir to a different location. 

    See this blogpost i made for some examples: https://how2appvirtualize.blogspot.com/2019/01/how-to-use-dynamic-scripting-in-your.html

    • Edited by Arne Johansen Tuesday, July 9, 2019 11:48 AM updated post
    • Marked as answer by Bryn Rogers Thursday, August 15, 2019 11:55 AM
    Tuesday, July 9, 2019 11:34 AM

All replies

  • Hi, like the solution suggest, this is COW protected file (.dll) and can't be modified inside the VE without hacking APPV folder rights (not recommended).
    My quickfix would be merging the virtual directory where calendar.dll resides  with local filesystem and then script the folder creation into base os during add package event or on publishing  (mkdir c:\xxx) and set correct permission on the dir with icalcs on the next step.
    Then Delete calendar.dll (as i understand that's the file that's being modified) from your package and copy it into your script folder in the package.
    Then make a script in your package that copy this file into the local folder during add or publishing of package after the first script has created it and put the correct icacls rights on it. 

    Then your application should see the folder and dll with the correct file/folder permissions and be able to modify it. Remember to put a delete command on file/folder on package removal.
    I do this all the time with old sh*tty sw packages.

    From a security perspective it may be better to redirect the local folder with a junctionpoint to a folder share where you can isolate rights more easily with AD groups and without compromising system security.

    And remember this solution may give you some problems is if there is several versions of the same program on the same system at the same time, and they all need access to different version of the file. Then you need to modify installdir to a different location. 

    See this blogpost i made for some examples: https://how2appvirtualize.blogspot.com/2019/01/how-to-use-dynamic-scripting-in-your.html

    • Edited by Arne Johansen Tuesday, July 9, 2019 11:48 AM updated post
    • Marked as answer by Bryn Rogers Thursday, August 15, 2019 11:55 AM
    Tuesday, July 9, 2019 11:34 AM