From patchwork Mon Feb 5 20:34:49 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlos O'Donell X-Patchwork-Id: 25826 Received: (qmail 23303 invoked by alias); 5 Feb 2018 20:34:56 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 22805 invoked by uid 89); 5 Feb 2018 20:34:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:209.85.220.193, H*RU:209.85.220.193, central, contract X-HELO: mail-qk0-f193.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=g0YSqYZDbJZiKG1eY3L2/cCm25hJCE2P04A/surSfVE=; b=dEcrIPfi9HhdWoV3GpYlV0E5kC8Mpsf13l2TH8TFpFILVOaov8aNpsHmt9zFlTn5BV NhDd1QG4DpE1YNV1ac7EU9R9/+2ImozNbE82DvxHu0NvfSpJm+tmBDg9pBm7tWs2ibgW f6MTP/bCjS/gE/NWOAOW/fb7bLKlXeLjbRtT4d0vgqV11uZ0LX9ohgKupn/fl2X3ZrVP 6FVQ1bamlKMHhfk5ZvBEnEQklR3khvz1RdllQbn2rkbRHzpOJIT4wpE7pO5COwhyMqm8 CHw+Wc05GabhZLz4mCx33wF8r7lH8ZdJ14td1B6hlDeug4SMY6UzMQuBXNEyf49oWShT Ctrw== X-Gm-Message-State: APf1xPBilP+Pz3KZuaIXhXzZeNf+1LNi6Lv5s0Tm2ObxYws76yKcidrm p9Zi1Ww1gjdNO+011bY4c9ufDA== X-Google-Smtp-Source: AH8x227XeRMe2Vw9dfbMXXOkGd0KWbRVaTOtvZ8JGVQbUcCrjKPZVND80rgV49gg3/PGWFYKd3RAsQ== X-Received: by 10.55.143.5 with SMTP id r5mr43764qkd.357.1517862893176; Mon, 05 Feb 2018 12:34:53 -0800 (PST) To: Michael Kerrisk , "linux-man@vger.kernel.org" , GNU C Library Cc: Florian Weimer From: Carlos O'Donell Subject: [PATCH] getcwd.3: Mention that "(unreachable)" is no longer returned for glibc > 2.27. Message-ID: <94a3f8a3-5c0e-9fa5-ce2c-3f7e4b097a97@redhat.com> Date: Mon, 5 Feb 2018 12:34:49 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Michael, With glibc fix 52a713fdd0a30e1bd79818e2e3c4ab44ddca1a94 for CVE-2018-1000001 (Sourceware BZ #22679) the implementation in the just released glibc 2.27 has been changed such that instead of returning "(unreachable)" the implementation now returns ENOENT as it would have if the current directory had been unlinked. I see that in 2015 the quirk was documented in commit a2ac97c78bf05a55f8f616fc39a4724372dcfa95, and this is no longer true with glibc 2.27, but may continue to be true in other C libraries, so I reference NOTES from the paragraph in the central text. Signed-off-by: Carlos O'Donell diff --git a/man3/getcwd.3 b/man3/getcwd.3 index ff953a7d0..3c41736c9 100644 --- a/man3/getcwd.3 +++ b/man3/getcwd.3 @@ -91,7 +91,9 @@ the current directory into another mount namespace. When dealing with paths from untrusted sources, callers of these functions should consider checking whether the returned path starts with '/' or '(' to avoid misinterpreting an unreachable path -as a relative path. +as a relative path. This is no longer true under some C libraries, +see +.BR NOTES . .PP The .BR getcwd () @@ -270,6 +272,16 @@ generic implementation is called. Only in that case can these calls fail under Linux with .BR EACCES . +.PP +Since Linux commit v2.6.36 which added "(unreachable)" the glibc +.BR getcwd () +has failed to conform to POSIX and returned a relative path when the API +contract requires an absolute path. With glibc 2.27 onwards this is corrected; +calling +.BR getcwd () +from such a path will now result in failure with +.BR ENOENT . + .PP These functions are often used to save the location of the current working directory for the purpose of returning to it later.