[Pkg-sysvinit-devel] Bug#626263: Clarification of §10.5 symlink wording needed

[Russ Allbery]

Roger Leigh <rleigh at codelibre.net> writes:

> I am, however, unsure if the policy is the ideal solution today compared
> with 1998 when the Linux VFS was much more primitive.  I am yet to be
> convinced that the absolute link is better technically.  One thing I'm
> wanting to do (when time allows) is work on merging /usr and / where
> /usr would become a symlink to /.  That link would be "/" or ".." and
> having it absolute would not be good if you look up the path
> /chroot/usr/bin/foo since you'll actually get /bin/foo on the host,
> where the path might not even be valid (it might be /usr/bin/foo).  With
> a relative link it will always work correctly.  This is exactly the same
> issue as the /var/run symlink.

Yeah, it's basically a tradeoff between chroot handling and "nested"
symlinks.  I suppose I'm probably old-school here, in that I learned how
to do UNIX system administration before such things as bind mounts and
back when disks were tiny, so I've used top-level symlinks to move things
around a lot and appreciated Debian's care in ensuring that didn't break
symlinks.  However, Bill correctly points out that the world has moved on
and bind mounts are usually a better solution.

I'm not sure bind mounts work in some cases, though, such as if you want
to symlink a top-level directory into an AFS file system.

The "solution" to the chroot problem is to always manipulate the chroot
via chroot, which ensures that the view of everything in the chroot is
consistent.  But I realize that's not always feasible or obvious.  (Again,
something that I'm used to doing due to other issues over the years, but
which may no longer be "current".)

> Other than the rather special use case for absolute links for top level
> dirs, I'm not sure that absolute links are preferable to relative.
> Although chroot environments are a special case, absolute symlinks in
> the chroot could cause serious problems on the host if a link in the
> chroot points to somewhere on the host; you might end up using the wrong
> programs, libraries, or even blowing away a huge chunk of the host's
> filesystem.

I would say, though, that I consider it pretty dangerous to manipulate a
chroot environment without using chroot.  It's way too easy to
accidentally ascend out of the chroot and do things you didn't intend to
do, and if you're already doing things as root, there's absolutely no
reason not to just stick a chroot invocation in front of your command.

> I guess from the policy POV this is concerns what we consider to be
> acceptable practice for a sysadmin.  While the policy caters for admins
> who create symlinks for top-level directories, this practice does not
> extend to subdirectories--where things would still break.  Symlinks can
> be fragile, and we have much better means to rearrange the filesystem
> now--and this applies to all the platforms we support, not just Linux.

> From the POV of packaging, I'd like symlinks to point to a specific
> place, without ambiguity, and in the context of chroots, a relative link
> is unambiguous whereas an absolute link changes depending on where we
> are rooted.

Yeah, this makes sense.  Maybe it's time to reconsider this policy.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>