misc/184340: PATH_MAX not interoperable with Linux

[Bruce Evans]

On Wed, 27 Nov 2013, Brooks Davis wrote:

> On Wed, Nov 27, 2013 at 11:03:31PM +0000, David Cundiff wrote:
> > Change PATH_MAX in kernel to 4096 from 1024. Should be harmless and will fix the issue in any program that uses PATH_MAX from the kernel headers. Also would allow longer 32-bit unicode paths.

Gak.

> Blindly changing PATH_MAX would be far from harmless.  It would bloat
> many internal structures and break ABIs and thus could not be done on
> a stable branch without quite a bit of work.  This is probalby worth
> fixing for 11.0, ideally by removing the limit entierly as suggested by
> POSIX.

Should be almost as easy as changing NGROUPS_MAX :-).

There is an interesting problem for the Linux (or any) compatibility layer.
It cannot emulate a larger PATH_MAX than the native one.  The emulated
sysconf(__SC_PATH_MAX) returns the native PATH_MAX, but that might be
incompatible with the emulated system's PATH_MAX.  I don't see how this
can work unless applications only use sysconf(__SC_PATH_MAX), but few
applications are that portable.

Similarly with all limits.  There is obviously a problem if the host
limit is smaller.  There might even be be a problem if the host limit
is larger, if the compatibility layer doesn't deal with it.  But the
compatibility layer doesn't even deal with security-related things
like uid truncation in linux_getuid16().  Larger uids on the host are
an example of where the host limit (UID_MAX here) being larger causes
problems.  The compatibility layer can't quite deal with this since
getuid() is broken as designed and can't fail (and no one checks for
it failing).  The best it can do is return an unprivileged 16-bit id.
nobody = 65534 is OK.  Sysadmins can deal with this by never using
uids above 65535, except there are a couple of reserved uids (one for
nfs) near UINT32_MAX.  sysconf() and pathconf() doesn't seem to be
emulated.

Bruce