Re: Issues on Umit while identifying paths in a portable manner

[Fyodor <fyodor () insecure org>]

On Tue, Aug 07, 2007 at 08:37:09AM -0300, Adriano Monteiro wrote:
> files, I figured out that it shouldn't be as such. I got many reports
> everywhere from users stating that they were having problems with the
> configuration file location, and also having problems whit old
> configuration files. Those more experienced with umit, found out that
> simply removing ~/.umit should solve most of these problems.
> Unfortunatelly, a regular user won't figure that out so easily.

Hi Adriano.  I agree that this is a major issue and am glad you are
addressing it.  I don't know what the perfect solution is, but maybe
your wisdom and help from the nmap-dev community will help.  Here are
what I consider the biggest problems with the current system:

o When you start Umit for the first time, a bunch of critical Umit
  files are silently copied to your home/data directory.  Even if you
  have never customized them.  Then the next time you upgrade Umit, it
  uses these old files instead of its newer ones.  This generally causes
  the new Umit to crash with a strange warning on startup.  But even if
  that problem was fixed, it would lead to users running old versions of
  important data files with their new Umit.

o Some of those silently copied files include customized path
  information which often causes problems.  For example, if I run umit
  from the SVN directory, various relative paths get copied to my
  ~/.umit .  Then when I install it and try to run it again from the
  new install directory, everything crashes.

o When I try to run umit from a directory other than that in which the
  binary resides, I often get a crash.  Even if I rm -rf ~/.umit
  first.  For example:

  flog~>rm -rf ~/.umit
  flog~>~/umit-sf-svn/trunk/umit
  Traceback (most recent call last):
    File "/home/fyodor/umit-sf-svn/trunk/umit", line 47, in ?
      Path.set_umit_conf(config_files)
    File "/home/fyodor/umit-sf-svn/trunk/umitCore/Paths.py", line 103, in set_umit_conf
      config_file = self.config_parser.read(umit_conf)
    File "/home/fyodor/umit-sf-svn/trunk/umitCore/UmitConfigParser.py", line 60, in read
      raise Exception("Couldn't find any usable config file!")
  Exception: Couldn't find any usable config file!

o The umit file configuration system is completely undocumented, so
  users/developers basically have to figure out how it works through
  trial and error or code reading.

I don't know the best solution, but here are some ideas which might
work well in various combinations:

o Instead of handling changes by copying all of the data files and
  then letting the user modify them through Umit, you could just save
  the user's modifications.  For example, you could save new scan
  profiles created by the user in a special file or file section for
  this purpose.  Then after you load in the normal default profiles,
  you could load in any user-added customized profiles.  This approach
  might not allow users to delete standard profiles, but that is
  perfectly fine by me.

o The files could be copied only when a user actually changes them.
  Right now, a bunch of files such as options.xml, umit.conf,
  wizard.xml, profile_editor.xml etc. are copied at first Umit startup
  even if you never execute a scan or configure anything.

o A more reliable approach could be used to store the location of
  Umit-related files.  Nmap compiles the data directory into the
  binary on Unix, but this causes problems (e.g. we cannot make
  relocatable RPMs).

o The system should be documented

Note that Nmap allows you to copy data files such as nmap-os-db,
nmap-services, or nmap-service-probes and will use those in preference
to the defaults.  But Nmap doesn't copy them automatically, so it is
assumed that people know what they are getting themselves into when
they do so.

I hope this helps, even if I don't have a perfect solution :).

-F

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org