The main means for a sysadmin to edit information in the database
on the fly will be a web based application that will allow the sysadmin
to search the database for information and edit it. The general outline
of the application's behavior starts with the administrator entering a
URL into a web browser. They will then be prompted to enter their username
and password into a radius login window. They will be presented with a
greeting screen and a command menu. From this menu they will be presented
with several search choices that essentially maintain the divisions one
is used to with the standard UNIX flat file system. These searches will
then present a paged list (X entries with a prev/next choice) of hyper
links for the user to look at. If the user is in the ACL with edit permissions,
they will see edit buttons next to the entries. If the user clicks on the
link, they will see a notecard format screen of all the user's vital information
(or group's). If they hit the edit button, they will be prompted
with a second radius login. This is to prevent users with permission from
leaving their web browser on the search page and allowing passersby to
muck with the password/shadow/group files. They will get an editable notecard
view of the vital info. This section will time out after a little while
for security purposes. They will most likely be presented with the existing
data with a matching text/form box near it for them to enter the new data.
When they submit, the change, the system will check that the data has not
changed since the last read. If it hasn't the write is completed, and a
message stating such is displayed. If it has changed, the new notecard
is redisplayed with the edited (form) fields intact, and the changed reference
date in place and probably in a noticeable color. After the edit is complete,
the user will be forced to logging again to do a new edit (edit login,
not the whole application login). The application will connect to the DB
through the RATS client side daemon rather than directly. This means it
will be allocated a number of API calls. We have not yet decided if it
will be better to restrict the api calls to the host with the DB on it
and require the web server for this app to reside on the DB server, or
to permit remote access to the API calls. We do however recommend that
this application be run on a secure web server. In addition, to the security
already described, the sysadmin may also make the cgi executable or not
as needed so the application is not available 24-7 for people to attack.
Keep in mind that this application is for small on the fly changes, and
is not meant for altering large portions of data at one sitting. The double
login is ugly, but it is essential to keep people from walking away from
the application and leaving a point and click hole in their security. On
the other hand, people leave their desks with their doors open and their
workstations unlocked with root logins.