named and /proc

[Tim]

On Sat, 2005-10-08 at 09:07 -0500, akonstam at trinity.edu wrote:
> Can someone explain this. When you run named using the init.d script
> the following things happen:
> 1, The proc directory appears in /var/named/chroot

I would imagine that this is because named needs to use something that's
in /proc but can't do so in its chrooted environment, so /proc is
replicated in it for it.

> 2. A link that can only be followed by root between /etc/named.conf
> and /var/named/chroot/etc/named.conf

Nothing other than root and named ought to be able to read named's
files.  Again, because of the chrooted named environment, named can't
read /etc.  Named has its configuration file in its chrooted
environment, instead (/var/named/chroot/etc) and there's a link pointing
to it from /etc/ for anything else (such as us) that would like to
use /etc/named.conf.

I'm not overly convinced of the worth of chrooting named.  While it may
stop some fault in named from exploiting the system, that won't some
other fault from being able to changed named's files.  Are we going to
chroot everything??

> 3. Then when you run df you get a result that does not refer to
> /dev/proc being mounted on /proc

I seem to recall reading that /proc was becoming deprecated?  If so,
maybe it's only here for the few things that still want it (e.g. named).
But perhaps df doesn't bother assessing systems mounted with special
purposes that don't occupy real disc space (e.g. proc)?  (It doesn't
list /sys/ either.)

> 4. However if you run df as a normal user you get something like this:
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /dev/hda4             17584528  14897032   1779824  90% /
> /dev/shm                257420         0    257420   0% /dev/shm
> /dev/hda2              1019240    620428    346200  65% /hda2
> df: `/var/named/chroot/proc': Permission denied
> sol:/users           207409664 124978336  71895488  64% /users
> 
> Why suddenly is df concerned about /var/named/chroot/proc?

Interesting discovery, I can only confirm that it does what you're
saying, not why.

My first quick thought would have been permissions preventing an
ordinary user from having anything to do with /var/named/chroot, but
then there's plenty of other inaccessible to normal user stuff in /var
that df doesn't protest about.

-- 
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.