W3C home > Mailing lists > Public > www-jigsaw@w3.org > November to December 1996

RE: AutoStarting Resource (was Request for feature: Logger.sync())

From: Alexandre Rafalovitch <alex@access.com.au>
Date: Fri, 15 Nov 1996 21:02:58 +1000
Message-Id: <v03007806aeb1fcc8b613@[]>
To: www-jigsaw@w3.org
>Alexandre Rafalovitch writes:
> > >Alexandre Rafalovitch writes:
> > > > At 9:03 PM +1000 12/11/96, Anselm Baird_Smith wrote:
> > > > I assume you want to use Timer entry to do checkpoint every N seconds.
> > > > Question is, how are you going to put Timer entry in the first
>place. If
> > > > you want to hardcode it, don't!
> > >
> > >Well, the problem with the httpd timer object, is that it's already a
> > >bottleneck (and as commiting changes might take long time, you really
> > >want a separate thread to run the code)
> > >
> >
> > You mean it is a bottleneck because it is used for client timeouts? Would
> > establishing a second timer object (system vs client timers) solve the
> > situation?
>Probably, what I meant is that the httpd.timer object is one of the
>very few that serialized all hits to the server: all thread handling a
>connection have to get through it to register the timer, etc (as is the
>logger for example).
>Having a second timer costs a thread...

Yes, that is true but what are the alternatives. And the cost is not that
high, is it? Other issues than an extra thread could be more important

> >  BTW, there should be some security on who can put what on Timer. Maybe
> > making timer resource package protected (default protection) would do the
> > trick?
> >
> > Then the second timer would be accessable through the public function and
> > can have less priority as well as maybe a bit tougher securityManager
> > protection.
>A lot of work will be needed to create a suitable security manager for
>Jigsaw, as a rough estimate, I would say that nearly all the methods
>of httpd would have to go through a secuirity check (they all return
>sensitive data, such as the root resource, etc).
Not really. We can assume two things. First, there are no static methods on
the server that give out any information. Second, non-secure resources
(CGIs, Servlet before authorisations, agents, etc) would not have access to
the server because their bridges (eg CGIResource) would not expose server
objects to them.

Those two things would mean that non-authorised resources would not be able
to access server things. They still can create all those nasty threads,
Sockets and file objects, but this is where we will need a real security
manager. So, I would say, don't worry about protecting the server.


Received on Friday, 15 November 1996 05:01:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:41:21 UTC