Jonathan S. Shapiro wrote:
>
> > > 1. If the user has the authority to run the program, and also has the
> > > authority associate a program with the web server, they have the
> > > authority to cause the web server to run the program, *regardless of
> > > what the program does*.
> >
> > The user may have authority to run a program, but not to connect it
> > to a socket which goes to the Internet.
>
> In this instance, however, it is the web server that has socket
> authorities, so the protective limitation is whether the user has the
> right to install CGI programs.
OK.
> Note that if the program is confined there is little danger in letting
> it talk to the internet -- the user can only expose their own
> information.
I don't think it is quite as simple as that, but then I may, again, be missing something. Consider this scenario (assuming I'm running Apache-SSL). I'm a bank. I have account information for a client. That client has authenticated himself use a certificate. I wish to present confidential data that only he should see via the SSL connection. How can EROS assure that this happens?
> > > 3. If a user has the write to replace a "file", they have the right to
> > > install a filter in front of it.
> >
> > But it may well be desirable to grant the right to filter without the
> > right to replace. E.g. I can write a pretty printer for EROS source, but
> > I can't modify it.
>
> This is a logical impossibility. There is no way to determine
> automatically what the filter does, so there is no way to determine
> that the filter does not itself replace the content.
> This is why I
> framed the permissions the way I did. The "publisher" of the content
> should have the ability to control filtering. *Perhaps* the server
> administrator should, but this is much less clear.
>
> > The server needs to pick up the TCP connection once the request is over,
> > in order to handle the next pipelined request. Is that a problem?
>
> The server can retain the socket, but there is no way to know what the
> status of the connection is at that time. In particular, the server
> cannot rely on the CGI program to honor the HTTP protocol correctly.
CGIs do not honour the HTTP protocol. The webserver does that. CGIs should not be talking to the HTTP socket.
> Ahh. The server-controlled wrapper program can guarantee this.
Good!
Cheers,
Ben.
-- Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org and Technical Director|Email: ben@algroup.co.uk | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache