Entering all security bugs and tasks for SeaMonkey into Buzilla for schedule tracking.
Summary: Connect visibility filter to query principals → Connect XPConnect visibility filter to query principals
The following message details the existing interface for security control of XPConnect. We need to add an implementation of nsIXPCSecurityManager that looks at the stack to see if the caller is sufficiently privileged to access XPCOM components. Subject: nsIXPCSecurityManager Date: Fri, 04 Jun 1999 12:09:47 -0700 From: email@example.com (John Bandhauer) Organization: N E T S C A P E To: Norris Boyd <firstname.lastname@example.org> CC: Mike McCabe <email@example.com> , Mike Ang <firstname.lastname@example.org> , Clayton Lewis <email@example.com> I finally got around to implementing the xpconnect security hook scheme I spoke of before. See the interface at: http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/idl/nsIXPCSecurityManager .idl Its installation at: http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/public/nsIXPConnect.h#181 And its test at: http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/tests/TestXPC.cpp#490 http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/tests/TestXPC.cpp#951 John.
Not enough time to implement for M9.
Whiteboard: Code in, but disabled. Caused orange trees on Linux
Code is in, but the body of nsScriptSecurityManager::CheckXPCPermissions is ifdef'd out. When it was enabled, it caused orange trees on the Linux tinderbox (builds passed, but tests failed). I don't know what sort of failures it caused or how to run those tests.
Whiteboard: Code in, but disabled. Caused orange trees on Linux → Help wanted: Code in, but disabled. Caused orange trees on Linux
Whiteboard: Help wanted: Code in, but disabled. Caused orange trees on Linux → Should work with GetSubjectPrincipal Linux fix
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
Whiteboard: Should work with GetSubjectPrincipal Linux fix
Any chance that nsScriptSecurityManager::CheckXPCPermissions has been re-enabled, and no longer causes orange trees? I will check on 7261 dependencies. If dependencies are satisfied, I'll set this verified. (dependency 7268 will require a simple set of DOM security tests that should pass to satisfy "initial implementation".) (dependency 11145 verified)
Yes, the preference is no longer disabled but doesn't cause any known regressions.
Bulk moving all Browser Security bugs to new Security: General component. The previous Security component for Browser will be deleted.
Component: Security → Security: General
Verified based upon dependencies being verified.
You need to log in before you can comment on or make changes to this bug.