I couldn’t log in again yesterday, even had problems today.
So, done all that (I think). Now make.exe is fine and I know what you mean by dbl clicking on the rule and then on customize and then on Modify(x\x).
I added the Hugin rule in Modify(x\x).
However the random numbered batch files still require me to click on each one of them when they appear in Comodo and each one appears in D+ as a rule with several entries in their own Modify(x\x).
Looking at your first suggestion again for the make.exe - I’m not sure I have done what you suggested - it’s just not clear to me from what you wrote.
I now have a rule for make.exe with a custom policy with Run an executable with 2 settings:
C:\Windows\SysWOW64\cmd.exe
and my Hugin rule which is
C:\Users\Administrator\AppData\Temp\make*-.bat
C:AppsVideo\Hugin\bin*.exe
E:\CanonPics*\make-.bat
C:\Users\ADMIN~1\AppData\Temp\make-*.bat
and in Protected files/folders Modify has the above Hugin rule.
Move one of the random number BAT file rules (that CIS generated automatically) next to your own Hugin rule… make the window/fields bigger if needed, take a screen shot of it & post it here.
Also, your E drive. What sort of HDD is that? Normal internal HDD? Removable HDD? Network HDD?
Not as safe as Kail’s fine tuned approach, but making the files that create and run the batch files installer-updaters may work. You seem to have tried this but I’m not sure you got all the right files. Identify these by watching the active processes list in CIS during a make. Sometimes making the root IDE executable an installer is what works.
An example of someone who has used this approach here.
To make the policy effective you need to enable it by ticking "automatically detect installer updaters’ and “automatically trust files from trusted installers” on the sandbox tab of D+ settings
If this works be careful not run run any risky executables from your dev environment.
Thanks for the reply, we’ll get it eventually!
Can’t see any ntvdm.exe in D+.
I will change back to the “fine tuned approach” and will do the other things you suggest but probably not this weekend. Busy busy!
OK, I’ve tried making the root IDE executable (make.exe) an installer and checked that this is done:
<To make the policy effective you need to enable it by ticking "automatically detect installer updaters’ and “automatically trust files from trusted installers” on the sandbox tab of D+ settings>.
But no joy.
make.exe still creates the temporary .bat files and each one of these is executed somewhere from 5 to 8 times per panorama, each time requiring clicking Comodo to say OK.
Just installed Hugin myself. At the align stage of the process I get:
hugin.exe
cmd.exe
make.exe
Initially then some even longer calling sequences involving cmd.exe with different files involved.
Make then appears to create the batch file. I get a sandbox alert for the batch file.
Making Hugin.exe, rather than make.exe an installer/updater does resolve this. The entire sequence through to the creation of the stitched file then seems to work without alerts, probably because everything or almost everything seems to happen in one calling tree. (Though I get some ‘make still busy on a previous job’ warnings and have to re-run some stages, I think this could be because I have abandoned some processes part way through, or because I am working on a slow machine).
If this does not work for you please post the exact text - or even better a screen shot - of any remaining alerts you are getting. I suspect you make have some corrupt or bespoke settings which are causing problems.
I figured it out late last night and into the early hours of this morning.
I’ve done a walk through for future travelers.
A) Add a Hugin group to groups in protected files and folders.
I had to use the exact string Comodo uses:
\CanonPics*\make*-?.bat
\Users\ etc
NOT C:\Users\ etc or E:\CanonPics\ etc
and not Administrator but ADMINI~1
A) was the key stumbling block for me.
B) Add the Hugin group to Defense+Rules
Edit the rule
Use a custom Policy and click Customize
3)Click Modify in Run as exe
4)Add the Hugin app \bin folder
Bingo
Oh you will also be asked by Comodo if one other app is OK to run: icpfind.exe
Just click OK and remember.
And that’s it
A couple of notes
Comodo is an unusually difficult program to use (perhaps because of the complexity of the field)
You have a Scumbag that has access to the so-called hidden email address’ of people who sign up on your website. I immediately started getting spam after signing up and I haven’t had spam in months.
Coincidence? Perhaps.
Thank both of you for your help - I couldn’t have done it without you!
This is more specific than my suggested solution (which also works) so safer I think.
Just one point of clarification for others. Protected files here is being used to access the ability to define groups within CIS. BDG is not defining more protected files.
Also one query. Does this really not work with ‘administrator’ in place of admini~1. Would worry me if true.
I apologize for resurrecting an older thread, but it contains a lot of info I’ve been using to try to fix a similar issue I’m running into running the latest version of hugin (2011.2.0) w/ Comodo.
I’m running Comodo Firewall 5.8.213334.2131 with the Firewall & Defense+ active and the Antivirus not installed.
I’ve been running Comodo for quite a number of years and in the past had relatively little problem giving proper access to applications as they needed them.
However, Comodo is now sandboxing the make####-#.bat file while trying to align images with hugin and I’ve tried the workaround in the earlier hugin thread as well as this one, but cannot get Comodo to allow hugin to spawn what it needs to work.
I set up a “hugin” group as described below (even tried adding the full paths, tried using the root drive letters, etc.), but even went more relaxed, i.e. I tried using even more inclusive wildcard settings:
and set that group up with a Custom Policy as BDG did within Defense+ Rules under Computer Security Policy (Run an executable > Modify > Allowed Applications > “C:\Program Files\Hugin\bin*”.
When I try to align images, I get a Comodo Security Alert that says “make####-#.bat is an unrecognized file and has been sandboxed as Partially Limited.”
I tried adding C:\WINDOWS\system32\cmd.exe and the “Temporary Files” group to Run an executable > Allowed Applications for the Custom policy of the hugin Defense+ Rules, but it didn’t work.
The only way I’ve been able to get Comodo to allow hugin to create and run the batch files is to set the hugin group as “Installer or Updater” within the Defense+ Rules under Computer Security Policy.
Is there a better/more secure way for me to get this working?
Using the Install/Updater or Windows System Application policies is the only way to handle dynamically created files.
Regarding security. You know hugin to be a legit application so in that sense there is no security risk in it creating those batch files. Other than that CIS will protect it from being tampered with. In short: you are very safe even when using powerful policies.
With 5.9, in theory, presuming the files that run the batch files are trusted, AND you make the batch files themselves trusted using wildcards and the new ‘trust by path’ mechanism, AND you make any file that the batch files run trusted, all should now work without the installer/updater policy.
Just for closure this does not work, as embedded wildcards are not allowed in trusted files, even when ‘trust by path’ is specified. Terminal wildcards are resolved when you add files, so this does not help either. (In any case making files in a temp directory all trusted is not sensible).
I wish I knew how to solve this. My only solution was to disable internet connexion and quit comodo completely (disabling defense+ didn’t even seem to work)…
(disabling defense+ didn’t even seem to work)…