Date: Mon, 2 Feb 1998 14:55:08 -0800 (PST) From: Alex Belits <abelits@phobos.illtel.denver.co.us> To: Adam Turoff <AdamT@smginc.com> Cc: Terry Lambert <tlambert@primenet.com>, hackers <hackers@FreeBSD.ORG> Subject: RE: WebAdmin Message-ID: <Pine.LNX.3.96.980202134853.24252A-100000@phobos.illtel.denver.co.us> In-Reply-To: <34D6373B@smginc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Feb 1998, Adam Turoff wrote: > > its actions as long as the client uses HTTP. > > Standardizing on HTTP as a client/server interface between multiple > clients has a lot of possibilities. First, we start with a well defined > API > to write the server side bits (the admin component subset will require > more structure than generic CGI), and the client side starts out with > a well defined API that's mostly implemented in almost any language > today. > > However, I'm concerned that HTTP 1.0 is a stateless protocol, and that > it's pretty much nothing more than a NFS with remote execution. HTTP > 1.1, > once everything supports it sufficiently, will handle the stateless part > with > keep-alive that actually works. Remote administration is stateless outside the boundaries of transaction. State that should be kept on the server outside the boundaries of transactions doesn't have to be kept on client, too, and Keep-Alive / persistent connections shouldn't be used for anything but decreasing response time. Neither HTTP 1.0 nor 1.1 have any means for sessions support -- sessions, if they are necessary, *need* identifiers, passed between server and client, however in the case of remote administration there are no sessions outside of already atomic transactions. > > Then there's also the question of security. Running a bunch of scripts > that create users and such against Apache is not secure. Picking a port > other than 80 or 8080 and possibly using SSL on it is marginally better. > > Since we're talking about system security, it sounds like we need a > better security model to establish connections than straight https. I'm > guessing writing a new httpd from existing libraries (or hacking Apache > to run as admind with a different authentication module) would have a > better > login model than standard httpd would solve this concern, hopefully > once and for all. HTTP "Basic" authentication over encrypted channel (ssh forwarding) is very secure unless server compromises it by its design. Running CGIs and Apache modules creates some (solvable) security problems, however CGI and Apache modules system are far from the perfect solution for this -- I wrote my own HTTP server with different interface to modules/processes exactly because the CGI or Apache modules system cut too many corners in the protocol and API design. > Once that issue can be settled, the next step is standardizing on a > remote call interface. This could be as simple as coming up with > a standard set of name=value pairs that both the client and server > would understand, or doing something a little more complex and > having the client perform resource discovery to see what the server > can do. I'd lean towards the latter, since it allows a much finer grain > of tuning for the sysadmin - i.e. let anyone log in and change their > shell, but only let root change a password and don't let anyone > change crontab. This is mostly a question of backend implementation. My idea is that filesystem-like hierarchy or URLs with lists of key-value pairs for data provides suitable way of assressing requests/changes, and permissions can be applied based on it, if necessary. -- Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.980202134853.24252A-100000>