From owner-freebsd-bugs@FreeBSD.ORG Thu Nov 28 01:58:40 2013 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B28F949C; Thu, 28 Nov 2013 01:58:40 +0000 (UTC) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 76A59C3F; Thu, 28 Nov 2013 01:58:40 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 16915D62072; Thu, 28 Nov 2013 12:58:30 +1100 (EST) Date: Thu, 28 Nov 2013 12:58:23 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Brooks Davis Subject: Re: misc/184340: PATH_MAX not interoperable with Linux In-Reply-To: <201311272330.rARNU1Rg003138@freefall.freebsd.org> Message-ID: <20131128123132.G2908@besplex.bde.org> References: <201311272330.rARNU1Rg003138@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=YYGEuWhf c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=CTnlIX1aa1AA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=cDWVyxjDliQA:10 a=lLiR8zBlVp3ex2TvZdkA:9 a=CjuIK1q_8ugA:10 Cc: freebsd-bugs@freebsd.org X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 01:58:40 -0000 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