Re: [Nautilus-list] future plans for the search feature

[Ryan Muldoon <rpmuldoon students wisc edu>]

I really like the goals of medusa, and I think it is a more key piece of
the overall puzzle than many have been giving it credit for.  Fast,
powerful searching is something that has a ton of uses.  So, having said
that, I'd like to make a few comments on your proposal.

On 03 Apr 2001 17:52:51 -0700, Rebecca Schulman wrote:

> 
> Here are some suggestions on how to deal with enabling and disabling
> medusa when it requires a root password:
> 
> (1)   Leave the "fast search" preference in its current place, but
> require a root password to turn the indexing feature on or off.
> 
> This choice seems to require relatively few code changes, but there
are
> a bunch of drawbacks.
> One is the issue of having a different "fast search" preference at
> different user levels.  If this happened,
> a user might be asked for their root password when changing user
levels,
> which would be strange indeed.  It's also not clear that a system
> setting like whether your computer is indexed or not is actually a
> "nautilus preference".
> 
Medusa really isn't a part of Nautilus, nor should it be.  It makes a
lot of sense for Nautilus to use it heavily, but medusa is and should
remain independent.  So having Medusa configuration in Nautilus is kind
of wrong-headed.


> (2)  Remove the ability to turn medusa on and off in nautilus for now.
> 
> We could include documentation about how to turn the search feature on
> as root in either the user manual, or as a dialog that came up when
the
> search feature was activated. This is easy to implement, but probably
> makes the search feature, which is already hard to use, worse.
> 
In my opinion, Medusa should default to being on, and power users can
turn it off if they really have issues with it.  Without a nice fast
index system, stuff like vFolders become basically impossible to use.
The goal should be to make medusa a basic system service, useful in of
itself, but combined with other things (like Nautilus) it is all that
much cooler.  People don't gripe about locate or slocate.  Medusa should
be trying to replace those.

> (3)  Make turning medusa on and off a "system preference" which is
done
> separately than other nautilus user preferences.
> 
> We could extend the "indexing information dialog" so that  you could
> enable and disable medusa from here. Making this work logically would
> also involve making the dialog available at all times, since it is
> currently only available when viewing search results (This is
> bugzilla.eazel.com bug 3254 http://bugzilla/show_bug.cgi?id=3254) 
This
> option would probably involve the highest level of code change of the
> options listed here.

This is probably the optimal (and long-term) solution.  Although I think
that 2 is fine, there will probably be a lot of people that will
complain for some dumb reason that there is no easy way to turn medusa
off.  Medusa should really have its own control center capplet that lets
users tweak usage, etc.  The only problem with this is that Medusa is,
and really should be, a system-wide indexing program.  This would
require that users be able to make system changes.  Which implies a new
control center architecture, and a solid framework for asking for the
root password across gnome when it is needed.  And a nice UI for it all.


> Here are some possible changes we could make to medusa to deal with
> current security issues.
> Some of these choices  will clearly affect the set of choices that we
> would make to the Nautilus UI.
> I've tried to list these choices in order of security risk.  In
general,
> this means that possibilities nearest
> the beginning will require the most implementation work, because they
> are the greatest departure from what we currently have.
> 
> These are the set of "low security risk" solutions that have been
> proposed:
> 
> (1) Make Medusa a personal service that only indexes home directories.
> Different users use the service separately, and can only do indexed
> searches on their own home directories.

This is really not a good idea.  Most people who have decent setups, or
even more than just one user on their system, are going to want to find
data from more than just their home directory.  

> (2) Do (1) but also create a configuration so that a user could
include
> other directories besides his/her home directory in what is indexed
> 
This really isn't much of an improvement over 1.....

> (3) Allow each user to index his/her home directory, possibly also
> including the extra feature in (2), and have a global index owned by
> "nobody" that would index the world writeable material on the drive.
> 
if you change "writeable" to "readable", this is becomes a lot more
workable.  I access files on a constant basis that I have no permissions
to write to.....just read.

> All of these would be large changes to the capabilities of "fast
search"
> and would necessitate a lot of changes the Nautilus UI as well as
> to medusa.
> 
> Here are solutions that in general would still present issues like
doing
> a complete security audit,
> and future security exploits:
> 
> (4) Leave the global user system as it is, but make the indices owned
by
> user "medusa", and make the search service run as user "medusa".

won't that cut out the ability to index your own files?

> (5) Leave the single index system in place, and take one or more of
the
> following steps to decrease security risks:
> 
> A  Include in the list of "unindexed files" commonly known files that
> would be very dangerous to share,
> like /etc/shadow which stores encrypted passwords in an unreadable
file
> to make dictionary attacks on passwords  harder.
This seems like it is just asking for an accident.  It would be too easy
to forget a file in the list.
> B.  Don't index files readable only by root
This sounds like a good solution to me.
> C.  Create a system where the search daemon runs only to process a
> single query and then exists,
> as slocate does.
> D.  Do a public audit of especially secure sections of code, including
> the authentication of clients,
> permissions checking, and other places where clients can send data to
> the search server.  A public audit could include posting this code to
> nautilus-list, gnome-hackers, or others.
> E.  Ask the assistance of Alan Cox, who according to Nat Friedman,
> Ximian worked with when developping Red Carpet to make sure medusa is
> secure.
Either D or E would probably work, but would also require that you do continual 
audits whenever you change affected code.  If slocate is already
"secure", and essentially does the indexing stuff mostly right, why not
just make that logic a library, and then build Medusa on top of that.
Then you can get all the extra nice features, without any security
problems.  


Anyway, those are my current thoughts on the matter...hopefully they are
useful.

    --Ryan