Re: System administration tool

[Dave Stagner <dave spnz org>]

On Mon, Apr 12, 1999 at 11:41:54AM -0500, Miguel de Icaza wrote:
> 
> > And then they're writing a GUI, reinventing the wheel.  CGI-style
> > programming is faster, easier, and more familiar to many programmers.
> 
> I do not understand how CGI-style programming is faster than using a
> GUI tool to design a form.  

Although i do believe it is faster, there are also several other
issues to consider.  

CGI-style programming is server-side only.  Without it, developers
have to write both the server module and the client (or offload lots
of server-side functionality to the "fat client").  And developers
need to worry about building and tearing down network connections.  If
authentication mechanisms change, every client author needs to be
aware of it (and servers need to maintain multiple authentication
mechanisms for various clients).  

We might simplify this away somewhat by putting all the generic parts
of the client in a CORBA object, but even then the client will have to
handle its graphics directly.  And, while GUI client coding may be
comfortable and familiar for *you*, it is mystifying voodoo to the
vast majority of Unix/Linux administrators i know.  Even if good RAD
tools are available, GUI programming is simply a different paradigm.
If developers are forced to do GUI programming for even the simplest
functionality, something that just runs a single command line program
(like, say, 'mount -t iso9660 /dev/cdrom /cdrom'), far fewer modules
will be written, and fewer will be maintained and extended.  

There are security issues involved as well.  If scripting languages
are used for clients (as i sincerely hope), such as Python or Perl
with GTK/GNOME extensions, then the exact commands being executed on
the server will be apparent - which provides unnecessary information
about system internals to users (remember, one problem i am trying to
solve here is to give users certain functionality that requires root
access, without actually requiring root passwords or suid operation).
Writing in C/C++ doesn't solve this completely - 'strings' will still
tell hostile users information about commands executed.  

Now, back to the browser-style client.  No security-sensitive
information is visible to the users... the actual commands executed
are hidden in server configuration files readable only by root.  There
are few adminstration functions i can think of that require graphical
functionality beyond the simple text boxes, radio buttons, etc of HTML
forms.  No clients need to be written - everything comes from the
server-side module and a command-line path parameter for one
system-provided client.  Programming methodology is familiar to all
programmers, not just those comfortable with GUI programming.  

So basically, i see a lot of advantages to the thin client approach
for flexibility, ease of development, and security.  It's not just a
matter of programmer convenience - and certainly, CGI-style
programming is no more difficult than using a GUI development tool.  
 
> > I'm well aware of that.  And, in the longer run, i may go for a
> > CORBA-based solution.  But in the short run, i don't know enough about
> > CORBA (especially within GNOME) to be comfortable with it.  
> 
> You do not need to know anything about CORBA and its GNOME
> interaction.  Just check out the tutorials on CORBA in either
> www.omg.org, or the ones on www.labs.redhat.com/orbit
> 
> At least read them, and then tell me why you do not like that
> approach.  But ditching a complete scheme because you have not studied
> it makes me a bit nervous (speaking from personal experience here).

To write *secure* code, with the security implementation working the
way i think is best, requires more understanding of CORBA (and the
ORBit implementation) than i have right now.  I'm not comfortable with
it because of my own lack of experience, not because of perceived
flaws in the model.  Reading the tutorial won't tell me the potential
gotchas of running an ORB as root when other ORBs in the same
environment are running under a regular user ID.  

I do hope to fully integrate this system into GNOME, using ORBit for
the server code.  But first things first... the configuration files,
module structure, access control list format, etc all need work.  
 
> > And ORBit still isn't mature technology.
> 
> Wonder how are you measuring matureness of ORBit.  It is being used
> all over GNOME: it works and any bugs reported are fixed with
> rapidity.  Do you have any specific complains or it is just the lack
> of "1.0" label on it?

Are all the features in place?  (bug-fix mode)  Are buffer overflow
conditions and other potential security flaws thoroughly beaten out of
the code yet?  There's a big difference between running well enough to
keep from crashing, and resisting concerted attacks on its security by
those with skill to study the source.  After all, the server i
envision *will* be running as root.  

And again, i'm certain that the feature set will be complete, and the
security thoroughly tested in the longer run.  But for now, the only
place it is used is on existing GNOME desktops, the bleeding edge.  It
hasn't seen widespread use and deliberate attacks yet.  When security
is at stake, only trial by fire is sufficient proof.  
 
> > I stepped back from CORBA for practical reasons on getting good work
> > done fast, and security worries that i don't yet know enough to
> > resolve.
> 
> We can help you with the security issues, you run away implementing
> the services, our team will help you with the security bits once you
> have something written.

Which will hopefully be soon.  :}  Unfortunately, i spent the weekend
rebuilding my crashed NT installation so i could have Quicken again.
Someday, Quicken will run under Linux.  

-dave

-- 
Practice beautiful randomness and act kind of senseless.