From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28012 invoked by alias); 1 Jun 2018 14:48:58 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 42913 Received: (qmail 19319 invoked by uid 1010); 1 Jun 2018 14:48:58 -0000 X-Qmail-Scanner-Diagnostics: from rcpt-mqugw.biglobe.ne.jp by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(133.208.100.2):SA:0(-2.6/5.0):. Processed in 0.900065 secs); 01 Jun 2018 14:48:58 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: takimoto-j@kba.biglobe.ne.jp X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | X-Biglobe-Sender: From: "Jun T." Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [Bug] Strange Globing Behaviour when used with sudo Date: Fri, 1 Jun 2018 23:08:30 +0900 References: <1527707719.3469997.1390875592.73AD29B6@webmail.messagingengine.com> <20180530202349.GA10754@osmium.lan> <20180531094403.05b62bee@camnpupstephen.cam.scsc.local> <20180531084938eucas1p19a854d9e9ea17428cd6549f56a283356~zroN76sl33019130191eucas1p1K@eucas1p1.samsung.com> <3977A049-90E6-4EDD-9E4C-8D2FF38593A3@kba.biglobe.ne.jp> <20180531152941eucas1p2c45927fa47f727224e2da98b4f6a7604~zxFgS-BM50307003070eucas1p2G@eucas1p2.samsung.com> <20180531181546.osffv3ysjzaxjfid@Daniels-MacBook-Air.local> To: zsh-workers@zsh.org In-Reply-To: <20180531181546.osffv3ysjzaxjfid@Daniels-MacBook-Air.local> Message-Id: <01B9BB58-DDAE-4056-AD9A-2367DC3AC20D@kba.biglobe.ne.jp> X-Mailer: Apple Mail (2.3273) X-Biglobe-Spnum: 57019 > 2018/06/01 03:15, Daniel Tameling wrote: > > As s is NULL and buf is in the example ./file/, statfullpath adds to > buf a . so that it's "./file/.". (snip) > So one possibility to fix this is to > call stat before adding the . to ./file/, and the return non-zero if > it is not a directory. Yes, but users can add '.' by themselves, for example sudo zsh -c 'echo */.'. And of course you can not just "return !S_ISDIR(st->st_mode)", and st may be NULL. I've also fond that stat("file/..") is similarly broken. In the patch below, I enclosed everything within "#ifdef __APPLE__" to minimize the side effects. It is difficult to detect the bug by configure since it requires sudo. diff --git a/Src/glob.c b/Src/glob.c index 66a95329f..95b3c7ca0 100644 --- a/Src/glob.c +++ b/Src/glob.c @@ -288,6 +288,26 @@ statfullpath(const char *s, struct stat *st, int l) DPUTS(strlen(s) + !*s + pathpos - pathbufcwd >= PATH_MAX, "BUG: statfullpath(): pathname too long"); strcpy(buf, pathbuf + pathbufcwd); + +#ifdef __APPLE__ + /* + * Workaround for broken stat()/lstat()/access() on macOS. + * If called by root, these syscalls mistakenly return success for + * path like "foo/bar/." or "foo/bar/.." even if "bar" is a file. + * We should make sure "bar" is a directory. + */ + if (!*s || !strcmp(s, ".") || !strcmp(s, "..")) { + struct stat stbuf; + if (stat(unmeta(buf), &stbuf) || !S_ISDIR(stbuf.st_mode)) + return -1; + if (strcmp(s, "..")) { /* done if s is "" or "." */ + if (st) + *st = stbuf; + return 0; + } + } +#endif + strcpy(buf + pathpos - pathbufcwd, s); if (!*s && *buf) { /*