System administration tool

[Dave Stagner <dave spnz org>]

I see there's some discussion of a system administration tool for
GNOME.  I've been doing design work on the same thing, and was
planning to start coding tomorrow.  I wasn't actually going to
announce anything until i had some working code, but given the
discussion, i thought i'd toss out my ideas for input, and to
stimulate any competing projects.  

I see two major problems that need to be addressed with such a
system.  The first is security.  Any fool can run suid root programs
from the desktop, and open up more holes in the system.  I think we
can do *much* better.  The second problem is generality.  I don't want
programmers to reinvent the wheel every time they want to add new
functionality (especially with security-sensitive code).  

What i'm planning is a client/server system where only the server runs
as root, and the client and server communicate via XML.  The server
will get its capabilities from a directory of configuration files,
which has access control lists, and descriptions of scripts/programs
to run.  It will work much like a simplified, secure web client/server
- the server will send the client XML, which the client interprets and
displays as standard GUI controls and parameters, much like HTML
forms.  The user selects parameters and clicks OK or something, and
the client sends the parameters to the server.  The server can then do
parameter substitution for command lines or scripts.  The client and
server will keep the connection alive, possibly for several "form"
transactions.  This will enable mult-screen sequential activities,
similar to Micros~1 "wizards" (one of the better things about the
Windows interface).  

Here are some of my considerations, in no particular order... 

* The user should not need the root password in order to perform
functions requiring root (such as mounting drives).  I want this to be
a tool for *sysadmins* who are trying to give the users necessary
functionality without giving them unnecessary access.  This is
essential if Linux is to be a corporate desktop
platform... administrators need simplified, flexible control of system
configuration without sacrificing security.  If we do this *right*, it
will be yet another place Linux beats Windows. 

* Programmers should not have to write an entire GUI to build a
GUI-based tool.  HTML forms are marvelous this way.  

* Programmers should be able to write functionality in any language,
particularly scripting languages like sh and Perl.  They shouldn't
be stuck with the languages that have gtk bindings.  

* More on scripting... most administrative functionality is quite
simple and isolated, better for scripting than high-level interfaces.
Developers shouldn't need to write 500 lines of GUI code to grab a
handful of parameters for a single shell command.  That way lies
Windows.  

* I'm not planning on using CORBA for now.  Not that i have anything
seriously against it... i just don't know it well enough to determine
whether or not it will work.  And i DO know basic Unix client/server
programming.  And of course, the fewer libraries involved, the easier
security will be.

* The configuration files will be as separate as possible from *my*
client and server code.  Others with different ideas about security or
implementation will be free to write their own - a KDE client, for
example - and still use the same set of configuration files.  All
files and interfaces will be XML with well-defined DTDs.  That's the
reference standard.  

* The server should be usable for non-root activities as well.  There
could be a server running under the user's own id, for managing
personal stuff.  So this general-purpose interface could be used for
things other than administrating the whole box.

* A common response to this sort of functionality is to "use Apache
and cgi".  I think this is a losing approach.  This is a
security-sensitive interface, and http fails there.  The
authentication mechanism is not tied directly to Unix authentication,
connections are dropped and picked up again (leading to icky kludges
like cookies), and both client and server do LOTS of things that a
locally secure system has no business doing (caching, anyone?)

Now, some notes on my client and server... 

Their working names are gnomad (GNOME ADministration) and mad
(something Administration Daemon... the M is silent or something :)

Communication will take place via a unix domain socket, which
guarantees locality.  This reduces the complexity of authentication
and increases security.  Others may wish to write a TCP/IP
server... good for them!  The server will authenticate the client
independently via OS mechanisms, which may be kludges - Unix doesn't
have a good mechanism for authenticating over unix-domain sockets (BSD
4.4 does, but i don't have that functionality in Linux or most other
unices).  Establishing the authentication mechanism is my coding goal
for the weekend.  Until security works, there's not much point in the
other stuff.  

The client will, of course, be for GNOME.  :}  I have a personal
interest in promoting GNOME as the desktop of choice for Linux, so i
want to provide the sort of functionality in GNOME that Linux is most
often criticized for lacking.  

If you've stayed with me this long, thank you.  :}  What do you think?

-- 
Practice beautiful randomness and act kind of senseless.