On Tue, 2 Jan 2001, John Bandhauer wrote:
> Ari Heitner wrote:
> >
> > On further reflection, late registration of XPCOM components is key to Sash
> > (from the Sash webliction's point of view). That is, once you're running
> > untrusted JS (which is what Sash is all about; it's just that JS now has some
> > useful system libraries. if you're not careful, evil can easily ensue :), only
> > the components specifically permitted to this weblication should be
> > available. Currently, this is acheived by inserting XPCOM objects (representing
> > libraries authorized to the weblication) into the ComponentManager at
> > runtime. This seems to suggest that all we really need is runtime insertion of
> > typelibs, the same way we can register new XPCOM objects.
>
> This does not follow at all. Don't confuse type information with
> specific component implementations. I assume that you are talking
yes. i shouldn't infer behaviour for type registration from behaviour for
implementation registration. my fault.
> only about access via xpconnect from JavaScript to xpcom
> components written in C++. In that case the proper mechanism for
> security is to write an implemention of nsIXPCSecurityManager and
> install it using either
> nsIXPConnect::setSecurityManagerForJSContext or
> nsIXPConnect::setDefaultSecurityManager.
Sash has its own security policies and probably will not use mozilla's JS
security hardware, only for the reason that we're trying to maintain
consistency of concept with the Windows version (which is based on IE). The
only security issue is that we *do* need to be able to access *some* XPCOM
objects. But we *don't* want the JS doing arbitrary XPCOM stuff (since that can
amount to running arbitrary code, by replacing mozilla system objects with JS
implementations).
This is actually an issue i hadn't considered yet: if i turn on
UniversalXPConnect, create JS instances variables for a couple of classes, and
turn of UniversalXPConnect, will i be able to use those instances?
>
> What you say below does not make it clear that you really need to
> dynamically add type info to the set of known type information,
> only that you want to dynamically control access to the
> components. That is what nsIXPCSecurityManager is for. If your
> system does in fact have a finite set of xpt files known at
> startup time, then I don't see any reason to fiddle with xpti
> (other than to change where xpti finds those files in your
> system).
>
> Again, keep in mind that the component registry is not where xpti
> info is stored. xpti.dat is used as a cached 'index' to let xpti
> track where to find and load type info incrementally on demand.
> You *can* dynamically add new type info by writing new xpt files
> to the directory where those files are stored and forcing an
> autoregistration. This is not an activity for which xpti is
> particularly optimized.
>
Ok. So if there's really no such thing as "dynamic type info registration" (all
the typelibs have to be available and you have to do an
autoregistration). That's fine with us, we'd only have to do that on
installing/removing Sash extensions (libraries which provide new functionality
to Sash and therefore define new objects that can exist within Sash).
We *do* know about all available types at (weblication) startup time. But we
*don't* have access to $MOZILLA_FIVE_HOME/components.
So it sounds to me like we need support for multiple type info databases. But
we don't really need support for multiple component databases (since we can
perfectly happily continue to register those at runtime).
Is my head on straight yet ? :)
cheers,
ari
