Re: /usr vs. root was: /etc /usr/etc
Vadim Vygonets writes:
> 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.
OK. Fine thing to do.
> The reason
> ==========
[...]
Basically agreed, though the *needs* should be expressed first,
instead of first stating that config files should be divided in 2
groups, and then telling the advantages.
> The solutions
> =============
I'd: some of the solutions that were proposed
> 1. Moving various files to /usr/etc (the Simple Solution)
> =========================================================
[...]
Not much to say
> 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.
Agreed, this would be fine; but if we can a satisfying solution that
doesn't satisfy this point, I'll still be OK.
Just remember all decisions we'll have to take must be based on
technical issued, and not on other decisions that were already made by
other people; we should instead understand what the technical issues
involved in their decisions were. Does anybody know of a central
database of problems and which ones standard solutions address ?
> (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.
Quite agreed.
> 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).
Just look at the "Reply-To:" header-field, or my final sig :)
As you slightly distorted (IMO) what I tried to expose, I'll try to
correct:
> 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.
Sorry, I just proposed the concept; when coming to implementation, I
rather advocate this function be incorporated into libc. That's the
only way to eventually make it a standard.
> 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.
Maybe, but maybe not. Not all debian maintainers may be expert enough
to do this tweeking, and keep it in sync with upstream releases. The
best way to apply it would have it detected by autoconf, and used if
present, otherwise default to what we have now.
> 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.
Not exactly. What I proposed was adding to the ext2fs driver (not in a
new one) a directory-specific inode-property (applied in our case to
/etc), which would contain a path to another directory (in our case
/usr/etc), and of which the role would be to provide for non-existing
files in the first dir, the equivalent of a default softlink to a file
of the same name in the second directory.
Eg, if /etc/mime.types doesn't exist as a file, and /etc has this
property set to "../usr/etc", then the fs-driver would act as if there
has been a soft-link to "../usr/etc/mime.types".
> 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.
All depends which of the followings appears to be the most difficult:
1) have many many maintainers/developpers incorporate the call to
confopen(), with the risk of causing many bugs in many packages, or 2)
implement the mechanism in a kernel-driver, where every program would
transparently gain benefit from it.
> 2. The kernel is Linux-wide, while the solution to the problem
> will be Debian-specific.
Not at all, I this as a quite general mechanism.
> 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.
The packages' sources will not be changed, so there won't be any
difference from what wa have now, in this respect. Every distribution
might use another policy for handling this problem, but if we come
with such a general solution, they may even be able to use it at a low
cost.
> (b). This will exploit security holes.
This may be a strong argument against, I do agree.
> 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).
How would /usr/etc/whadow come from an intruder machine ? IMO, to do
that, the intruder would already have gained root priviledges. Or do I
miss something ?
> 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.
1: false, the mechanism does exist.
2: ???
3: `see above`
> (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.
OK. I already suggested an extension of ACL's, to take into account
the machine in addition to usual user/group scheme. OK, ACL's aren't
ready right now.
> (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.
Why this ? This is exactly what we want to work around with this !
> (d) This would make the remote /etc partition very very large, keeping
> up to several thousands of files (on large networks).
On the server, yes. Isn't it its role ?
> (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.
This will not be true when we'll have the machine-ACL extension I
suggest above (see (b))
> (f) This would require an additional mount point.
Yes. And ?
> Summary
> =======
>
> Maybe there were other solutions which I don't remember, but I think I
> expressed all of them (including my points of view).
You forgot rsync/cfengine, I think. Someone wants to develop about
this one ?
> 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.
Nope. I do not think it's time for now.
> Thank you.
Thanx to you for having gathered all this...
--
Yann Dirson <dirson@univ-mlv.fr>
http://monge.univ-mlv.fr/~dirson
--
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: