XFENCE forgets/deletes existing rules
This morning I spend 3 hours maintaining and refining rules. I also imported the Dropbox rules from the extras.
I often opened and closed the rules browser. After I fininshed I started getting a ton of popup from apps which I formerly gave full access to all files or to a specific folder. I also got the same popups repeatedly.
After confirming each dialog I opened the rules browser to search for the rules I just confirmed. To my surprise most of them weren't there anymore, for instance all the Dropbox rules are gone, all BetterTouchTool rules and many more.
I rebooted once again and spent another 10 minutes clicking on popups only to find that they didn't stick and are nowhere to be found in the rules browser.
I'm an admin user. That's all I can think of in regards of causes of defect.
The issue persists even after several reboots. Example: 
Once again, no trace of remind in my rules. I have to disable XFENCE for the time being since it has become unusable. I'm open for suggestions.
Comments
-
-
-
I received an answer a while ago. It's case XFENCE-00160 on the beta site… which is currently not available anymore. So, here's the solution (at least for me):
It is likely that you have path with a Umlauts or some non-standard UNICODE characters. This results in XFENCE creating linebreaks in your settings file.
If you're familiar with the command line try this:
grep --color '.allow\|.deny' /Users/Shared/F-Secure\ XFENCE/THE_NAME_OF_YOUR_FILE_HERE.xfence.rc
It will list all problematic sections. Delete them and when XFENCE asks again, select a lower path without the Umlaut. Instead of `~/Docs/Ärtze` this would be `~/Docs/`.
---
So, I managed to find the original answer by Rasmus Sten from the F-Secure dev team who helped me out quickly 3 Months ago:
@Rasmus Sten wrote:
Hi,
thanks for your report! This is in fact an issue that we have observed and that will be fixed in a future update. However we haven't figured out the exact root cause yet and as such I can't tell exactly when we'll be able to ship that update. Your detailed bug report will definitely help us nail this down, so we appreciate the effort you put into reporting this and I'm sorry about the frustration this bug has caused.
What happens is that XFENCE corrupts its own rule file, and then any further updates to it fail silently. The symptom is typically that a new rule line will begin before the end of the next line, joining into one (invalid) rule line. Currently I suspect this primarily happens when a rule involves non-ASCII (i.e. Unicode) path names due to faulty assumptions of byte count in Unicode paths. One example from one of your rule files is:
allow prefix "~/Library/Application Support/Übersicht/" "/usr/bin/ditto via /Applications/Übersicht.app/Contents/MacOS/Übersicht" rwc "" "" "allow prefix "/System/Library/Components/AppleScript.component/" "/Applications/DragThing.app/Contents/Resources/DragThing Helper.app/Contents/MacOS/DragThing Helper" r "" "9A6GM5K6XE" "1499859963"
This is all on a single line and if you look closely you can see a second "allow" in the middle of the line, indicating that this is actually two rule lines merged into one.
When this happens XFENCE will not be able to parse the complete rule file anymore and any rule after the invalid line will be ignored.
A workaround for this is to manually remove the offending rules from the rules file using a text editor (naturally, XFENCE needs to be disabled first), and then when adding new rules, try to express them in such a way that you can avoid non-ASCII paths.
To find the offending rules, you can do the following in Terminal:
cd "/Users/Shared/F-Secure XFENCE"
grep --color '.allow\|.deny' *.rc
…and it should display the invalid rules with the corrupted "allow/deny" highlighted in color. Once XFENCE is disabled you can edit the .rc file using e.g. TextEdit or your favorite text editor and remove the offending lines.
Let me know if you manage to work around the problem using these steps. Sorry again for the trouble this has caused!
- Rasmus, F-Secure R&D -
-
Hello,
Just interesting (because I do not able to re-check with my own steps):
It's case XFENCE-00160 on the beta site… which is currently not available anymore
Do you mean that beta-portal (or F-SECURE XFENCE project) is not available anymore?
Because -> with my experience: beta-portal still possible to use; And F-Secure XFENCE project still marked as available opportunity under public F-Secure resources/webpages (even maybe is not valid already).
Thanks!
-
I was unable to find it yesterday. My irritation was because XFence wasn't listed in F-Secure > Website Footer > Beta Programs (https://www.f-secure.com/en/web/labs_global/beta-programs). The only app for home users there is FS Protection.
I had to search my emails for the correct login. Here's a link to the case number, don't know if it's public or just for my account: https://beta.f-secure.com
-
another-account wrote:I was unable to find it yesterday. My irritation was because XFence wasn't listed in F-Secure > Website Footer > Beta Programs (https://www.f-secure.com/en/web/labs_global/beta-programs). The only app for home users there is FS Protection.
I had to search my emails for the correct login. Here's a link to the case number, don't know if it's public or just for my account: https://beta.f-secure.com
Hello,
I'm not sure how it with F-Secure XFENCE project, but usually reports/cases under beta-portal is visible only for you (and F-Secure staff; or maybe for this ones who allowed to see it). Such as not a public tracker.
// and, yes, main beta programs webpage do not list "Xfence". Just as clarification: 'by public F-Secure websites/resources" I did talk about Xfence promo page (and 'available'-status under beta-portal):
https://campaigns.f-secure.com/xfence/
Thanks!
🚩 What Do You Think?
We’d love your thoughts on our fresh look! Quick survey, big impact!