Bug#922674: debian-policy: make symlink requirements consistent

[sothrt+f20muazw5tue8]

Package: debian-policy
Followup-For: Bug #922674

Dear Maintainer,

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039979 has come up as 
something to consider regarding this related change in debian policy.

In that context, I'd advocate for permitting '..' in symlinks, even if only as 
an exception for those specific paths to enable safer working with chroots.

Bug#922674: debian-policy: make symlink requirements consistent

[Russ Allbery]

Ansgar Burchardt  writes:

> It seems strange to treat top-level directories differently: why
> should /usr be allowed to be a symlink, but /usr/local, /usr/lib or
> /usr/share/doc not?  I can't come up with a better idea than that
> top-level directories are something like "driver letters".

I think the rationale was just that it was more common to move top-level
directories to another drive with more space than it was to muck about
below the top level.  I'm not sure we document that difference anywhere
useful for the user, though.

> So I suggest to either:

> (a) require *all* symlinks to be relative
> (b) forbid using '..' in symlinks

Personally, I prefer (b) -- I think relative symlinks that ascend out of a
directory are a questionable pattern in general.  But this is a very large
change that would affect a lot of packages (admittedly, in a way that
could mostly be cleaned up by debhelper), and is also a pretty significant
break with past practice that will probably break some system out there in
some way.

-- 
Russ Allbery (r...@debian.org)   

Bug#922674: debian-policy: make symlink requirements consistent

[Steve Kowalik]

On 19/2/19 8:50 pm, Ansgar Burchardt wrote:

It seems strange to treat top-level directories differently: why
should /usr be allowed to be a symlink, but /usr/local, /usr/lib or
/usr/share/doc not?  I can't come up with a better idea than that
top-level directories are something like "driver letters".

So I suggest to either:

(a) require *all* symlinks to be relative
(b) forbid using '..' in symlinks


You target directories, but don't mention files in your wording, and I
think forbidding use of '..' in symlinks unilaterally is the wrong
approach, for this simple reason:

steven@wrecked:~% find /usr/share/doc -type l -exec ls -l "{}" \; | grep 
-c '\.\./.*Debian.gz'

746

If the wording  was ratcheted down to forbidding '..' for symlinking
directories, I think I'm okay with it.

Cheers,
--
Steve
"Yes, let's not jump to any conclusions."
"I didn't jump. I took a tiny step, and there conclusions were."
 - Rupert Giles vs Buffy Summers

Bug#922674: debian-policy: make symlink requirements consistent

[Ansgar Burchardt]

Package: debian-policy
Version: 4.3.0.2
Severity: normal

Policy 10.5 (Symbolic links) currently has two classes of requirements:

Symlinks between /${x} and /${x} (same top-level directory) must use
relative links; symlinks between /${x} and /${y} (different top-level
directories).

The historic reasons[1][2] point out this is to allow /usr (or other
top-level directories) to be a symlink to somewhere else which would
break symlinks using '..' in their target.

It seems strange to treat top-level directories differently: why
should /usr be allowed to be a symlink, but /usr/local, /usr/lib or
/usr/share/doc not?  I can't come up with a better idea than that
top-level directories are something like "driver letters".

So I suggest to either:

(a) require *all* symlinks to be relative
(b) forbid using '..' in symlinks

(a) would imply that users would have to use bind-mounts instead of
symlinks; (b) would allow any directory to be a symlink, but require
tools acting on chroots to be aware of symlinks (but they have to be
that already as we sometimes require absolute symlinks already).

Ansgar

  [1] https://lists.debian.org/debian-policy/1998/04/msg00110.html
  [2] https://lists.debian.org/debian-policy/1998/03/msg00050.html