On Fri, Aug 15, 2008 at 07:49:14PM +0200, Gerfried Fuchs wrote: > * Lionel Elie Mamane <[EMAIL PROTECTED]> [2008-08-15 16:47:41 CEST]:
>> During Manoj's "policy" talk at DebConf8, Gerfried opened the >> subject of the policy's stand on relative and absolute symlinks, >> which currently is "absolute if going through top-level, relative >> otherwise". >> So, is there any reason at all to use relative symlinks? I had a quick chat with Manoj, and he makes the following point: Say someone has the /usr/share/doc of a Debian machine on a separate partition, say /dev/sdb7. Now, he boots into a FreeBSD installation on the same machine and mounts /dev/sdb7 on /mnt/debian-doc; then relative symlinks within the Debian /usr/share/doc work, but absolute symlinks don't. Similarly, if one NFS-mounts Debian's /usr/share/doc on /mnt/debian-doc of another machine. Or accessing a file from a chroot from the parent filesystem (without actually chrooting into the chroot). One could argue that to handle this scenario, Unices need an additional mounting option "map-symlinks=/usr/share/doc" that would strip /usr/share/doc from absolute symlinks in that partition and (if it stripped) stick the mount point path in front of them. However, having the whole world change in order to accommodate our eventual "only absolute symlinks" policy is not a practical solution :) My gut feeling is that "make everything work within Debian" takes priority over "make rarer / manually setup scenarios work" when there is a hard conflict, meaning we should use absolute symlinks when the conflict arises. In other words, for a specific directory, our good reason to disallow relative symlinks through it (that is it may be a symlink itself) outweighs our good reason to require relative symlinks through it (that is, it may be mounted elsewhere), in cases both apply. A maybe out-of-the-hand way to make the problem disappear is to specify our users should not use symlinks to move things to another physical place, but that they should use only mounts (I'm thinking of rbind mounts to a shared mount to replace symlinks). Then, all relative symlinks is good. If we don't do that, the core question is "what directory is somewhat likely to be a separate partition / symlink to elsewhere"? (And a symlink that escapes the scope of such a directory must then be absolute.) My list would be: - most top-level directories: /var, /usr, /opt, /boot, /home, /srv/ - /usr/local - most (direct) subdirectories of /var/ or /usr/ - actually, any "big" (in space)) hierarchy; /usr/share/games, /usr/share/docs, /var/lib/mysql, ... and some package-specific directories. To take the example of mailman, I can imagine people doing that with the whole /var/lib/mailman, but also with only /var/lib/mailman/archives or /etc/mailman/templates. So it seems hard to have a predefined list in policy; maybe we should document the problem in the reference manual and let maintainers make case-by-case decisions. Or policy could say something along the lines of: A symlink must be relative if it escapes the scope of a directory that users may, for reasons of size, different mount options or other, want to replace by a symlink to another physical location. Examples include the top-level directories, /usr/share/doc, /usr/share, /var/log, ... -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
