From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 15 04:12:57 2020 Received: (at submit) by debbugs.gnu.org; 15 Sep 2020 08:12:58 +0000 Received: from localhost ([127.0.0.1]:57120 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kI659-0001ke-Sk for submit@debbugs.gnu.org; Tue, 15 Sep 2020 04:12:57 -0400 Received: from lists.gnu.org ([209.51.188.17]:53924) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kHzp2-0008EN-DP for submit@debbugs.gnu.org; Mon, 14 Sep 2020 21:31:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54648) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kHzp1-0007iu-VR for bug-coreutils@gnu.org; Mon, 14 Sep 2020 21:31:52 -0400 Received: from w1.tutanota.de ([81.3.6.162]:50362) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kHzoy-0006Xy-P2 for bug-coreutils@gnu.org; Mon, 14 Sep 2020 21:31:51 -0400 Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id B8AC7FA0486 for ; Tue, 15 Sep 2020 01:31:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1600133503; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=NYcG4s+U8WvVKPXawHRw6onaKTwqngAyg88FU0stJGs=; b=TTmp4+xqBV9QBWpU9/dCA8zM8kPrY7On726KrzraEDKr20XzYvrnPCM/CAKYbM31 DT4akyo9nfRhWg3zvXzOOM0Wm5Mgtz/1LNDdF7VrDrMuFfNvjZ08GaABeduyNmUz8By 2QmkvCazCWftpXGNCaN5QAMOQBZZVaaPL3VlrV/ksGBOphIMQcgT1cPWIxdwHrTHiL/ ZHUWsCLogN7seJ/8U2alYt2hyI6kUFnf7KTT2WgmJTgV3f0+/i9qsSmRon+QBuSavGK vM01ylxiGRTl8ByZgTITGPU4qredtawyp8OHXnvmM1zXgQIa01jCabMFmlNQxm+8eMp qSyXNrgaOA== Date: Tue, 15 Sep 2020 03:31:43 +0200 (CEST) From: Cameron Nemo To: bug-coreutils@gnu.org Message-ID: Subject: coreutils 8.32: install: fchmod fails with EBADF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11201_126443306.1600133503735" Received-SPF: pass client-ip=81.3.6.162; envelope-from=cnemo@tutanota.com; helo=w1.tutanota.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/14 21:31:43 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Tue, 15 Sep 2020 04:12:50 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) ------=_Part_11201_126443306.1600133503735 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I am experiencing some curious behavior when trying to set the file mode us= ing the install command. Version info: install (GNU coreutils) 8.32 Summary of behavior: fchmod to 1777 fails with EBADF The log from strace shows the following: =C2=A0=C2=A0=C2=A0 ... =C2=A0=C2=A0=C2=A0 geteuid()=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0 =C2=A0=C2=A0=C2=A0 umask(000)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 022 =C2=A0=C2=A0=C2=A0 mkdirat(AT_FDCWD, "tmp", 01755)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =3D -1 EEXIST (File exists) =C2=A0=C2=A0=C2=A0 openat(AT_FDCWD, "tmp", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_L= ARGEFILE|O_PATH|O_DIRECTORY) =3D 3 =C2=A0=C2=A0=C2=A0 fstat(3, {st_mode=3DS_IFDIR|S_ISVTX|0755, st_size=3D40, = ...}) =3D 0 =C2=A0=C2=A0=C2=A0 fchmod(3, 01777)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =3D -1 EBADF (Bad file descriptor) =C2=A0=C2=A0=C2=A0 fcntl(3, F_GETFD)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =3D 0 =C2=A0=C2=A0=C2=A0 fchmodat(AT_FDCWD, "/proc/self/fd/3", 01777) =3D 0 =C2=A0=C2=A0=C2=A0 close(3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0 =C2=A0=C2=A0=C2=A0 ... For some odd reason, the call to fchmod is failing with EBADF. This is causing the chmod() function to fall back to using an fd link in /p= roc. Normally (i.e. when /proc is mounted) this poses no issues. But I am trying to use the install command in a bootstrap/chroot environmen= t, and having to incorporate mount and unmount logic adds a significant amount= of non-idempodent complexity. It seems like relying on the /proc link is not ideal, and a bug is being hidden by such behavior. Is there any chance that this can be resolved? Regards, -- Cameron Nemo ------=_Part_11201_126443306.1600133503735 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I am experiencing some curious beh= avior when trying to set the file mode using
the install comm= and.

Version info: install (GNU coreutils) 8.3= 2

Summary of behavior: fchmod to 1777 fails wi= th EBADF

The log from strace shows the followi= ng:

    ...
 = ;   geteuid()        &nbs= p;            &= nbsp;         =3D 0
&= nbsp;   umask(000)        = ;            &n= bsp;         =3D 022
=     mkdirat(AT_FDCWD, "tmp", 01755)    &= nbsp;    =3D -1 EEXIST (File exists)
 &nb= sp;  openat(AT_FDCWD, "tmp", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE|= O_PATH|O_DIRECTORY) =3D 3
    fstat(3, {st_mod= e=3DS_IFDIR|S_ISVTX|0755, st_size=3D40, ...}) =3D 0
 &nb= sp;  fchmod(3, 01777)        &= nbsp;           &nbs= p;   =3D -1 EBADF (Bad file descriptor)
  = ;  fcntl(3, F_GETFD)        &n= bsp;            = ;  =3D 0
    fchmodat(AT_FDCWD, "/proc/se= lf/fd/3", 01777) =3D 0
    close(3)  = ;            &n= bsp;            = ;     =3D 0
    ...

For some odd reason, the call to fchmod is failing w= ith EBADF.
This is causing the chmod() function to fall back = to using an fd link in /proc.

Normally (i.e. w= hen /proc is mounted) this poses no issues.
But I am trying t= o use the install command in a bootstrap/chroot environment,
= and having to incorporate mount and unmount logic adds a significant amount= of
non-idempodent complexity.

I= t seems like relying on the /proc link is not ideal,
and a bu= g is being hidden by such behavior.
Is there any chance that = this can be resolved?

Regards,
-= -
Cameron Nemo
------=_Part_11201_126443306.1600133503735-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 15 19:49:14 2020 Received: (at 43415) by debbugs.gnu.org; 15 Sep 2020 23:49:14 +0000 Received: from localhost ([127.0.0.1]:60913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kIKhF-00013F-U8 for submit@debbugs.gnu.org; Tue, 15 Sep 2020 19:49:14 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:32938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kIKhD-000132-TR for 43415@debbugs.gnu.org; Tue, 15 Sep 2020 19:49:13 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 790F51600DE; Tue, 15 Sep 2020 16:49:05 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id weiYpGtWsRph; Tue, 15 Sep 2020 16:49:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9CDC81600F1; Tue, 15 Sep 2020 16:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XvrEhma2lUuu; Tue, 15 Sep 2020 16:49:04 -0700 (PDT) Received: from [192.168.1.9] (cpe-75-82-69-226.socal.res.rr.com [75.82.69.226]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 777B21600DE; Tue, 15 Sep 2020 16:49:04 -0700 (PDT) Subject: Re: bug#43415: coreutils 8.32: install: fchmod fails with EBADF To: Cameron Nemo References: From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDVlFRVEFRZ0FQ d0liQXdZTApDUWdIQXdJR0ZRZ0NDUW9MQkJZQ0F3RUNIZ0VDRjRBV0lRUitONUtwMkt6MzFq TzhGWWp0bCtrT1lxcCtOQVVDClh5Vzlsd1VKRks0THN3QUtDUkR0bCtrT1lxcCtOS05WRC85 SE1zSTE2MDZuMFV1VFhId0lUc3lPakFJOVNET1QKK0MzRFV2NnFsTTVCSDJuV0FNVGlJaXlB NXVnbHNKdjkzb2kydk50RmYvUS9tLzFjblpXZ25WbkV4a3lMSTRFTgpTZDF1QnZyMC9sQ1Nk UGxQME1nNkdXU3BYTXUreDB2ZFQwQWFaTk9URTBGblB1b2xkYzNYRDc2QzJxZzhzWC9pCmF4 WFRLSHk5UCtCbEFxL0NzNy9weERRMEV6U24wVVNaMkMwbDV2djRQTXBBL3BpY25TNks2MDlK dkRHYU9SbXcKWmVYSVpxUU5aVitaUXMrVVl0Vm9ndURUcWJ5M0lVWTFJOEJsWEhScHRhajlB TW40VW9oL0NxcFFsVm9qb3lXbApIcWFGbm5KQktlRjBodko5U0F5YWx3dXpBakc3dlFXMDdN WW5jYU9GbTB3b2lLYmc1SkxPOEY0U0JUSWt1TzBECkNmOW5MQWF5NlZzQjRyendkRWZSd2pQ TFlBbjdNUjNmdkhDRXpmcmtsZFRyYWlCTzFUMGllREs4MEk3c0xmNnAKTWVDWUkxOXBVbHgw L05STUdDZGRpRklRZGZ0aEtXWEdSUzVMQXM4andCZjhINkc1UFdpblByRUlhb21JUDIxaQp2 dWhRRDA3YllxOUlpSWRlbGpqVWRIY0dJMGkvQjRNNTZaYWE4RmYzOGluaU9sckRZQ21ZV1I0 ZENXWml1UWVaCjNPZ3FlUXM5YTZqVHZnZERHVm1SVnFZK2p6azhQbGFIZmNvazhST2hGY0hL a2NmaHVCaEwyNWhsUklzaFJET0UKc2tYcUt3bnpyYnFnYTNHWFpYZnNYQW9GYnpOaExkTHY5 QStMSkFZU2tYUDYvNXFkVHBFTFZHb3N5SDg4NFZkYgpCcGtHSTA0b1lWcXVsYmtDRFFSTWdI SmtBUkFBcG9YcnZ4UDNESWZqQ05PdFhVL1Bkd01TaEtkWC9SbFNzNVBmCnVuVjF3YktQOGhl clhIcnZRZEZWcUVDYVRTeG1saHpiazhYMFBrWTlnY1ZhVTJPNDlUM3FzT2QxY0hlRjUyWUYK R0V0MExoc0JlTWpnTlg1dVoxVjc2cjhneWVWbEZwV1diMFNJd0pVQkhyRFhleEY2N3VwZVJi MnZkSEJqWUROZQp5U24rMEI3Z0ZFcXZWbVp1K0xhZHVkRHA2a1FMamF0RnZIUUhVU0dOc2hC bmtrY2FUYmlJOVBzdDBHQ2MyYWl6Cm5CaVBQQTJXUXhBUGxQUmgzT0dUc241VEhBRG1ianFZ NkZFTUxhc1ZYOERTQ2JsTXZMd05lTy84U3h6aUJpZGgKcUxwSkNxZFFSV0hrdTVYeGdJa0dl S096NU9MRHZYSFdKeWFmckVZamprUzZBazZCNXo2c3ZLbGlDbFduakhRYwpqbFB6eW9GRmdL VEVmY3FEeENqNFJZMEQwRGd0RkQwTmZ5ZU9pZHJTQi9TelRlMmh3cnlRRTNycFNpcW8rMGNH CmR6aDR5QUhLWUorVXJYWjRwOTNaaGpHZktEMXhsck5ZRGxXeVc5UEdtYnZxRnVEbWlJQVFm OVdEL3d6RWZJQ2MKK0YrdURESSt1WWtSeFVGcDkyeWttZGhERUZnMXlqWXNVOGlHVTY5YUh5 dmhxMzZ6NHpjdHZicWhSTnpPV0IxYgpWSi9kSU1EdnNFeEdjWFFWRElUN3NETlh2MHdFM2pL U0twcDdOREcxb1hVWEwrMitTRjk5S2p5NzUzQWJRU0FtCkg2MTdmeUJOd2hKV3ZRWWcrbVV2 UHBpR090c2VzOUVYVUkzbFM0djBNRWFQRzQzZmxFczFVUisxcnBGUVdWSG8KMXkxT08rc0FF UUVBQVlrQ1BBUVlBUWdBSmdJYkRCWWhCSDQza3FuWXJQZldNN3dWaU8yWDZRNWlxbjQwQlFK ZgpKYjJ6QlFrVXJndlBBQW9KRU8yWDZRNWlxbjQwY25NUC8xN0NnVWtYVDlhSUpyaVBNOHdi Y2VZcmNsNytiZFlFCmY3OVNsd1NiYkhON1I0Q29JSkZPbE45Uy8zNHR5cEdWWXZwZ21DSkRZ RlRCeHlQTzkyaU1YRGdBNCtjV0h6dDUKVDFhWU85aHNLaGg3dkR0Sys2UHJvWkdjKzA4Z1VU WEhoYjk3aE1NUWhrbkpsbmZqcFNFQzllbTkwNkZVK0k5MwpUMWZUR3VwbkJhM2FXY0s4ak0w SmFCR2J5MmhHMVMzb2xhRExTVHRCSU5OQlltdnVXUjlNS09oaHFEcmxrNWN3CkZESkxoNU5y WHRlRVkwOFdBemNMekczcGtyWFBIa0ZlTVF0ZnFrMGpMZEdHdkdDM05DSWtxWXJkTGhpUnZH cHIKdTM4QzI2UkVuNWY0STB2R0UzVmZJWEhlOFRNQ05tUXV0MU50TXVVbXBESXkxYUx4R3p1 cHRVaG5PSk4vL3IrVgpqRFBvaTNMT3lTTllwaHFlL2RNdWJzZlVyNm9oUDQxbUtGODFGdXdJ NGFtcUp0cnFJTDJ5cWF4M2EwcWxmd0N4ClhmdGllcUpjdWVrWCtlQ1BEQ0tyWU1YUjBGWWd3 cEcySVRaVUd0ckVqRVNsRTZEc2N4NzM0SEtkcjVPUklvY0wKVVVLRU9HZWlVNkRHaEdGZGI1 VHd1MFNuK3UxbVVQRE4wTSsrQ2RNdkNsSUU4a2xvNEc5MUVPSW11MVVwYjh4YwpPUFF3eGgx andxU3JVNVF3b05tU1llZ1FTSExwSVV1ckZ6MWlRVWgxdnBQWHpLaW5rV0VxdjRJcUExY2lM K0x5CnlTdUxrcDdNc0pwVlJNYldKQ05XT09TYmFING9EQko1ZEhNR2MzNXg1bW9zQ2s5MFBY a251RkREc1lIZkRvNXMKbWY5bG82WVh4N045Cj0zTGFJCi0tLS0tRU5EIFBHUCBQVUJMSUMg S0VZIEJMT0NLLS0tLS0K Organization: UCLA Computer Science Department Message-ID: <76197137-2147-6c01-e33f-ae4bd95ea145@cs.ucla.edu> Date: Tue, 15 Sep 2020 16:49:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 43415 Cc: 43415@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 9/14/20 6:31 PM, Cameron Nemo via GNU coreutils Bug Reports wrote: > It seems like relying on the /proc link is not ideal, > and a bug is being hidden by such behavior. > Is there any chance that this can be resolved? It really should be fixed in the Linux kernel: it needs a proper way to implement POSIX fchmodat with the AT_SYMLINK_NOFOLLOW flag, in order to plug some security holes involving symlink attacks. See: https://bugzilla.redhat.com/show_bug.cgi?id=1810141 https://lkml.org/lkml/2020/6/9/548 In the meantime, mounting /proc may be your best bet. I vaguely recall there are other places in glibc that assume /proc.