none
App-V and apps that modify their own .bat batch files (or .cmd) RRS feed

  • Question

  • Hi there,

    From my testing, it seems that App-V has a certain security feature, which blocks editing, renaming, and even copying, of .exe, .bat, .cmd files, within tokenised program folders. Even with "allow full write permissions to VFS" and/or admin rights.

    Inside a bubble, either with or without admin rights, you cannot create .bat files, or edit them, or copy .exe files -- inside tokenised folders. You can quite happily do all these things as long as the target folder is outside the bubble.

    Eg I can copy AppVPackageDrive\somedir\file1.exe file to a location such as c:\scratch\, but I cannot copy AppVPackageDrive\somedir\file1.exe to AppVPackageDrive\somedir\file2 (nor rename it to file2.exe).

    Also (interestingly), if I put a .cmd, .bat or .exe file into %localappdata%\microsoft\appv\client\vfs\guid\token_folder\someplace, this can be seen (via dir) inside the bubble, but not executed, read, or copied (anywhere). So whilst I can over-write .ini files, for example, if I try to overwrite a .bat file by putting it in the users localappdata vfs, inside the bubble the original sequenced file will be seen, and the appdata file ignored.

    This causes a problem for me with a program that wants to modify a .bat file in response to user configuration changes. This does not seem to be possible/ supported by App-V, which blocks any and all changes to .bat files, and does not allow .bat files to be used from appdata locations.

    I guess the only answer is to take this file out of the package (and kept outside the bubble)... BUT...

    ...this means that there will be one .bat file for ALL users, and if any users change a setting this change will be for all users.

    Another thing I noted is that if I icacls the .bat file inside the bubble, things get weird very quickly. Not only to these files get copied to the localappdata vfs, with the new permissions, but the the permissions of the so-called "immutable" programdata vfs *also* get modified. I've even been able to accidentally delete files from this "immutable" package folder from within the bubble, once you start messing with icacls. Which I won't be doing in future :p

    Anyway, has anyone encountered this security feature, which I'm guessing is 100% by design? Tbh I'm not sure why this was even necessary. Other features such as AppLocker can prevent execution of rogue .exes, did App-V need to prevent self-modifying apps from working too?

    Thursday, July 28, 2016 2:53 PM

Answers

  • It is because of Copy-on-Write (CoW) exclusion.App-V 5.0 doesn't allow to write the .bat, .exe, .cmd and few more. To know more check this link from Tamim Karim.

    http://virtualvibes.co.uk/cow-and-its-exclusions-in-app-v-5-0/

    In App-V 5.1 it has reduced the number of Copy-on-Write (CoW) extensions from 59 to 4.

            - .exe

            - .dll

            - .ocx

            - .com


    (Please click on Vote as Helpful and/or Mark as Answer, if it has helped you.)

    MVP - Windows and Devices for IT

    app2pack.blogspot.com: app2pack.blogspot.com

    • Marked as answer by k9wazere Friday, July 29, 2016 10:53 AM
    Friday, July 29, 2016 7:17 AM

All replies

  • It is because of Copy-on-Write (CoW) exclusion.App-V 5.0 doesn't allow to write the .bat, .exe, .cmd and few more. To know more check this link from Tamim Karim.

    http://virtualvibes.co.uk/cow-and-its-exclusions-in-app-v-5-0/

    In App-V 5.1 it has reduced the number of Copy-on-Write (CoW) extensions from 59 to 4.

            - .exe

            - .dll

            - .ocx

            - .com


    (Please click on Vote as Helpful and/or Mark as Answer, if it has helped you.)

    MVP - Windows and Devices for IT

    app2pack.blogspot.com: app2pack.blogspot.com

    • Marked as answer by k9wazere Friday, July 29, 2016 10:53 AM
    Friday, July 29, 2016 7:17 AM
  • Thanks for the info. I did suspect it was by design, and it's good to know this won't be an issue when we move to App-V 5.1.

    It's weird tho, that I can use icacls within the bubble to give r/w permission to the .bat file, and this then allows it to be edited - not copied as you say, but edited in the program cache in c:\programdata. Naturally this then applies to all users.

    I guess the use of icacls inside app-v bubbles is not best practice :p

    e: also eve if I copy a .bat .cmd (etc) file into localappdata when the package is *not* in use, the package cannot execute (or read) these files when started.

    So as well as in-bubble editing not being possible, out-of-bubble editing via dropping in a new file is not supported either.

    • Edited by k9wazere Friday, July 29, 2016 8:46 AM more info
    Friday, July 29, 2016 8:35 AM
  • Curious what exactly you're modifying in the script itself and if it could instead be re-coded in a way to write the changes to an INI file or the user's registry hive, then have that data read by the script file?  Or, if the location and batch are hard coded (which it sounds like it is in the app) perhaps a symbolic link from the original bat location to the user's profile would work?  These should exist on a per-user basis and if the original file did NOT exist in the package, the app should be able to write to the sym link and not know the difference.

    Tuesday, August 9, 2016 2:54 PM