Closed Bug 7261 Opened 25 years ago Closed 25 years ago

Connect XPConnect visibility filter to query principals

Categories

(Core :: Security, defect, P3)

Product:
Core
Component:
Security
Platform:
All
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: norrisboyd, Assigned: norrisboyd)

References

Details

Entering all security bugs and tasks for SeaMonkey into Buzilla for schedule
tracking.
Blocks: 7252
Depends on: 7268
Status: NEW → ASSIGNED
Target Milestone: M9
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:
             jband@netscape.com (John Bandhauer)
 Organization:
             N E T S C A P E
         To:
             Norris Boyd <norris@netscape.com>
         CC:
             Mike McCabe <mccabe@netscape.com> , Mike Ang <mang@subcarrier.org>
,
             Clayton Lewis <clayton@netscape.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.
Target Milestone: M9 → M10
Not enough time to implement for M9.
Depends on: 11145
Blocks: 12633
Target Milestone: M10 → M11
No longer blocks: 7252
Blocks: 13017
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
Blocks: 10120
Whiteboard: Help wanted: Code in, but disabled. Caused orange trees on Linux → Should work with GetSubjectPrincipal Linux fix
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Whiteboard: Should work with GetSubjectPrincipal Linux fix
Blocks: 16950
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.
No longer blocks: 13017
Bulk moving all Browser Security bugs to new Security: General component.  The 
previous Security component for Browser will be deleted.
Component: Security → Security: General
No longer depends on: 7268
Verified based upon dependencies being verified.
No longer blocks: 10120, 12633
Status: RESOLVED → VERIFIED
No longer depends on: 11145
You need to log in before you can comment on or make changes to this bug.