[Nautilus-list] future plans for the search feature

[Rebecca Schulman <rebecka eazel com>]

We recently decided that potential/known  security issues involving
medusa were sufficient to warrant removing the fast search feature from
both nautilus for 1.0.1.  We will also be releasing 1.0.2
without the fast search feature.

If we would like to return to having a fast search feature in Nautilus,
we need to decide on two courses of action regarding how the feature
will work.  The first part of the plan is to remove the ability for
normal users to configure medusa's setup, and to change the Nautilus UI
to work accordingly.  The second step in the process is to decide on a
specification for the search feature that minimizes security risks, and
still remains close to our original vision for the feature so that we
can ship a Nautilus with medusa again in the next release (1.0.3) if at
all possible.

I have come up with a bunch of suggestions intended to address each part
of this plan.
Listed with each suggestion are the advantages and disadvantages of the
suggestion that I can see.
These lists are not intended as any set of decisions so further
discussion can certainly include things not here.


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".

(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.

(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.

I am not overly excited about any of these possibilities.  My personal
preference is to do (2) until we figure out what to do in the long term,
even though the UI is suboptimal, since it's likely work we do for this
may never be shipped.


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.

(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

(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.

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".

(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.
B.  Don't index files readable only by root
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.



Rebecca