On Fri, 20 Jun 1997, Paul Sutton wrote: > The admin server also needs to write to the configuration files, which > will probably be owned by a different user that the one that the main > server runs as.
Thats not a problem if the admin server is running as root. > In terms of who gets access to the admin functions, that I guess can > simply be setup by a command line initial install program where you select > one (or both) of a IP restriction and/or a username/password restriction. > That isn't a big issue. That initial install could just set up you access.conf on the admin server. > More important is that we don't want the back-end programs to allow other > local users to be able to either change to being another user or do things > to the main server (like HUPing it). If they are all owned and executible by root only, I dont see this as a problem. > I am assuming the interface will be based on a standard browser here to > allow for full adminstration from any networked system.. This is the great > advantage of the web over older applications. It would be a big step > backwards to use an admin tool that is OS specific and does not use a > browser as its transport. Agreed.. and as it was mentioned already, for more security just use a SSL server.. This would, of course require the use of a key authority... It would be ok to be your own key authority (I mean.. there is only going to be one user of this admin server and I think he would trust his own server).. BUT IE will not connect (nor even prompt the user) to a site using their own keyauthority (not on the IE trusted list of key authorities). ______________________________________________________________________________ Matthew J. Probst | Never underestimate the bandwidth of a station Sys. Programmer, BYU CS Dept |wagon full of tapes hurtling down the highway. [EMAIL PROTECTED] | -Andrew Tanenbaum
