Re: /usr vs. root was: /etc /usr/etc
Bruce, Brian: I'm asking from you to read this message and do
something about it, such as change Debian policy manual, take a votes,
or something. I think this is the time for a change.
On Sat, 5 Jul 1997, Behan Webster wrote:
> Actually, I have yet to see an impartial analysis of either
> method that compares each on their strengths and weaknesses.
> Most of the "debate" I've seen over this issue has amounted
> to people making subjective comments as to whether they feel that
> something is "ugly" or "sexy". No offense, but saying something
> is good (or bad) without explaining _why_ is not very useful.
> Especially in a technical discussion.
>
> Perhaps someone could start from the beginning, and first define
> the problem as they see it, then present all the solutions, and
> discuss their strengths and weaknesses.
Ok, as I started this thread, I would like to tell you what I think
about this topic, and present all the options in one message.
The reason
==========
In my opinion, config files in Debian Linux (as in any other Unix)
must divide into basically two portions: those that must be on the
root partition and those that must be on /usr partition. In my
opinion the config files (and this stands for other files, such as
programs, libraries, documentation and kernel(s), hehe) which must be
on the root partition are those that are _one_ (_or_ _more_) of:
(a) must be machine-local;
(b) essential at boot time;
(c) essential for maintainance in single-user mode, or in other
situations, where /usr is not available.
Comment: some of the machine-local configuration files ehich are not
needed at boot time or in single-user mode belong to /var, which must
be on local disk, but may be on separate partition, but this is not
relevant for our goals here, as I understand. So for this message,
let's consider /var a part of the root partition.
On the other hand, conffiles (and, let me repeat it, other files)
which belong to /usr are those that meet _all_ of the following
requirements:
(a) are site-wide;
(b) are not needed at boot time;
(c) are not required for maintainance in single-user mode.
This strict division of the files into these two groups serves various
purposes, two of which are to keep root partition as small as possible
and to ease system administrators' work on installation and upgrade of
the programs which belong to /usr (you must install or upgrade such
program only once, with all parts of it, on the fileserver).
My proposal of moving some configuration files from /etc, onto /usr
partition (the proposed name is /usr/etc), comes from the point of
view that some of the files currently found in /etc, by the definition
above, don't belong to root partition.
The solutions
=============
1. Moving various files to /usr/etc (the Simple Solution)
=========================================================
This solution is simple: move the config files that belong to /usr to
/usr/etc, and make no other efforts. That's the way it usually made
in other Unices. However, there were people who objected that some
people owning workstations mounting /usr from remote filesystem would
want to change the config files, which means, virtually moving the
config files from the site-wide category into machine-local category.
Then the other solutions were proposed.
2. Having symlinks in /etc poiting to /usr/etc (the Symlink Solution)
=====================================================================
This solution solves the problem explained in the Simple Solution, but
some people (including myself) pointed that, among the goals of /usr
partition, there are these ones:
(a) Installation of the program which belongs to /usr must happen only
once, on the fileserver providing the /usr partition, without
changing root partition on workstation, either manually or by a
script.
(b) The root partition must be as static (i.e. not changing) as
possible, i.e., once one installs the workstation, he must not
change the root partition on it unless there are any major
changes, for example, changing root password on all the workstation
on the network, upgrading a program in /bin or /sbin because of a
security hole, installing libc6 on all the workstations, and such,
but not things like upgrading a minor, non-essential program in
/usr.
3. Making the programs in Debian first seek for conffile in /etc, then
======================================================================
in /usr/etc (Yann's Solution)
=============================
Let me define this solution as `clean', because it solves both the
problems explaines above, in Simple Solution and Symlinks Solution.
Yann proposed two practial ways to acquire this. I'm really sorry,
but I don't remember Yann's last name (I only remember that his e-mail
address at the .fr (France) top-level domain).
3.a Write a function which will do it (Yann's Solution 1)
=========================================================
In this solution, Yann proposes to write the function which will try
to open the needed conffile in /etc, then in /usr/etc, and return the
`FILE *' to the first one found, or NULL if it fails. Sort of
enhanced fopen(). This function (during the discussion named
confopen()) would be distributed in the package dpkg-dev, or by any
other way, centralized, from Debian ftp site.
I, personally, like this solution most, because it solves the problems
defined above, and the problems defined below, in more complex
solutions, and is very simple.
There were people who said that this solution requires some source
code tuning, but the argument of the other side was that it's simple,
and anyway, Debian developers change the config file name, tune the
code and write packages, and it takes so much time, that this
extremely simple patch won't require much time and effort.
3.b Write a driver that will do it (Yann't Solution 2)
======================================================
In this solution, Yann proposes to write a driver for Linux kernel (or
module) which will redirect all the requests to access a file in the
/etc directory to /usr/etc, in case that the file is not found in
/etc, but is found in /usr/etc. This solution has its problems,
namely:
(a) This doesn't belong to kernel, for various reasons:
1. This is too difficult solution for this simple thing,
especially when we have Yann's Solution 1.
2. The kernel is Linux-wide, while the solution to the problem
will be Debian-specific.
3. This would require people who get a program from Debian for
their machine running another Linux distribution (or worse, any
other i386-based Unix supporting iBCS) to get the driver, or
forget about the matter.
(b). This will exploit security holes. For example, there are
programs which check for shadow passwords by checking if
/etc/shadow is present. If the driver redirects it to
/usr/etc/shadow, which may be taken from intruder's machine, this
program may give the intruder superuser priveleges (because he
knows the password).
By the way, the same problems are relevant to the solution defined
below.
4. Using patches from kernel 2.1 to mount remote /etc (the Remote /etc
======================================================================
Solution)
=========
There was a proposal to use a patch for unstable Linux kernel 2.1
family to mount remote /etc. This would lead to various problems.
(a) The problems expressed above, in 3.b Yann's Solution 2, problems
sections (a) 1 to 3.
(b) This would require the workstations to have /etc mounted
read-write, because the administrator of the workstation must be
able to change, add and remove the files in his /etc directory.
(c) This would require that there will be two copies of machine-local
config files: one copy on root partition, and the other copy on
the remote partition, and this would require the administrators to
keep them updated and identical.
(d) This would make the remote /etc partition very very large, keeping
up to several thousands of files (on large networks).
(e) This will not be secure enough, because root passwords for all the
workstations will be held in one place, and once the fileserver is
cracked, the intruder will obtain all the hashed passwords, or
change them.
(f) This would require an additional mount point.
Summary
=======
Maybe there were other solutions which I don't remember, but I think I
expressed all of them (including my points of view). I think that
now, as we see all of the solutions before us, everything is discussed
and everyone expressed his point of view, is the time to take some
action, to vote, to decide on the policy.
Thank you.
Vadik.
--
Vadim Vygonets * vadik@cs.huji.ac.il * vadik@debian.org * Unix admin
The fish doesn't think, because the fish knows... everything.
-- Arizona Dream
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: