Repository navigation
fix: distinguish browser database locks from OS permission errors - #17
Open
rajpreetcodes wants to merge 1 commit into
Open
rajpreetcodes wants to merge 1 commit into
rajpreetcodes wants to merge 1 commit into
Conversation
Fixes interplains#16. Previously, _locked_note() mapped any PermissionError or errno 13 to a message claiming that the browser was running and its database was locked. This produced misleading diagnostics when: 1. macOS TCC / terminal privacy permission denials were reported as running browsers with locked databases. 2. Profile directory enumeration failures on uninstalled or restricted browser remnants (such as Edge or Firefox) were falsely reported as the browser being installed and running. 3. On macOS, Firefox paths under ~/Library/Application Support were reported generically as 'the browser' because the marker search only looked for 'mozilla'. This commit: - Introduces _is_db_locked() to isolate real database locks (SQLite locks or Windows WinError 32 sharing violations) from OS permission denials. - Differentiates file and directory permission failures, reporting access denials truthfully while preserving honest coverage gaps. - Adds actionable guidance on macOS suggesting terminal permissions in System Settings > Privacy & Security (Full Disk Access). - Adds 'firefox' and 'chromium' markers so macOS Firefox and Chromium roots are properly identified. - Adds test coverage in test_browser_launch.py verifying diagnostic notes and gap recording.
scozzadroid-cpu
added a commit
to scozzadroid-cpu/zero-breach
that referenced
this pull request
Oct 28, 2026
android/ holds a root module that runs the pinned Zero Breach release (v0.1.8, taken from its git tag with a manifest of every bundled file) against the Chromium profiles, WebView data and app HTTP caches of an Android phone, on a weekday-night schedule that wakes the device from suspend. - web report page (module WebUI + standalone index.html) with an editable settings card; findings grouped per file - scheduled scans start only while charging by default (ONLY_CHARGING) - notifications only for new findings, failed/skipped scans and new upstream releases, verified as actually shown - self-check of the bundled upstream files before every scan - upstream's own IOC updater, fail-soft, previous list kept - LevelDB LOCK skipped and lock-vs-permission wording (upstream interplains#18, interplains#16/interplains#17) Upstream files are untouched.
Owner
|
Thank you for this, and for the careful write-up and tests. It's the right split: a real lock versus an OS refusal, plus the Firefox and Chromium naming on a Mac. The same fix, following your approach, shipped in Zero-Breach-Toolkit v0.1.9, which is where most of our work happens now. I'll come back to this PR when we decide what's next for this repo. PRs on the toolkit are very welcome too. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #16.
Problem
In
scan/adint_scan/modules/browser.py,_locked_note()previously mapped anyPermissionError,errno 13, or exception containing "locked" to a message stating that the browser was running and its database was locked.This caused several false diagnostics:
PermissionError: [Errno 1] Operation not permittedor[Errno 13] Permission denied. Zero Breach erroneously reported that the browser was running with a locked database, instructing users to close a browser that was already closed._locked_note(). When remnant directories for uninstalled browsers (such as Microsoft Edge or Firefox) existed with restricted permissions, Zero Breach reported those browsers as running with locked databases.~/Library/Application Support/Firefox/Profileswere reported generically as "the browser" because the marker search checked only for"mozilla".Solution
_is_db_locked()to detect genuine database locks: SQLiteOperationalError("database is locked" or "database is busy") and Windows sharing violations (WinError 32)._is_permission_denied()to detect OS permission denials (PermissionError,errno1 or 13,WinError 5, access denied)."firefox"and"chromium"to marker tuples so macOS Firefox and Chromium installations are accurately named in diagnostic notes.TestBrowserPermissionDiagnosticsinscan/tests/test_browser_launch.pycovering directory access denial, macOS permission guidance, profile enumeration gaps, database lock preservation, and browser naming.