Package: base-files Version: 10.1 Severity: normal Dear base-files maintainer,
I you will agree that it would be useful to provide /var/empty or /var/run/empty. Recently I became aware of #985459, and thought to myself "why not just use /var/empty?" as a way to defend against cases where root may have user-specific Emacs libraries installed to $HOME? Seconds of investigation later I was surprised to learn that Debian doesn't have one. This directory is present on Fedora, RedHat, CentOS, SUSE, Arch, FreeBSD, and possibly more. The FHS is silent about /var/empty, but I have been unable to discover why. In addition to helping to solve bugs like the one noted above, it seems like /var/empty could be useful in a CI or reprobuilds context. In the BSD world it was/is used for chroots, but of course this is becoming less relevant with their "jails" and this use will become less relevant as Linux namespace isolation becomes stronger. RPM-using distributions also use it for /var/empty/sshd where we use /var/run/sshd, so I wonder if /var/run/empty would be more appropriate in a Debian context? In operating systems that create per-server directories for use as chroots, /var/empty contains only directories. If /var/empty is not an immutable truly empty directory, and/or contains per-server subdirs, then a note in Policy to the effect of "/var/empty may contain directory trees, consisting only of directories, and must not contain any files anywhere". Considering this, an immutable and empty /var/run/empty seems like a cleaner solution. The regression potential appears to be negligible to nil. /var/empty should probably be chmod 755. I do not believe there are any security risks introduced by this proposal, but I think it would be neat if dpkg could tighten permissions to 555 or maybe even set the immutable bit after a package has been successfully installed. Thank you for your consideration :-) Nicholas
