From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29034 invoked from network); 14 Jan 2021 00:28:20 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 14 Jan 2021 00:28:20 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1610584100; b=lU2siro1nEepvgcv/05q/tLJzw77FIpRVmclvjHFEBBGtA/rqsyAdDhEqR+j5aPzkHHClaYnBH GEcWU9GKMF2k5AXUPctPCrQvs4zgFXhidu6TlU1gxjtPL1GgPNvEpYpJmCsJsx4iqE6M3c4DHe eNY0kKtmJTt72F0/TK5fhIfwbb3e1szLiJ/unJygqvCoyHOFStP5hKf0rVWGLK/7a2YaR76mey bv//wXu5Fd/rq+i6G4U7d8c9vYo5MNFNMMpqf9pQ2RjU00j/XULWtwxm9NaGvfV3G/b/vW+KbY RrQX9i71mPxuSMrvuJU5+04qIeCjkYi6F6wqmXsbk76Ycw==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-ua1-f52.google.com) smtp.remote-ip=209.85.222.52; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1610584100; bh=Ot2MucSdhPRZS42+5rvSy0LjqN4wuRJLeBzzRQxBbYg=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=dbEOBVwiAH/0KbonUTphHqnpfhKvJJudWlJMroi3IkRSpuMWF/P9UFYpVMWVIeiCf5LNEttLNA fldrfvWFjxvSt+t/vw6dTEsLsE73KdCzIkn5vf4q2/MLc8IwC52f+69RMpKZi3mRrZJQnC52UL 166YdTGWovRCSQpfOidNyzRZE4msl5bshDydIw6KzMlIRsUm3YQbT5Vh5TJSouK43qqmFvc9VR Hk1FuJTdfdNIurdzERBfcaZ/PXwCrveRdNekSj4LGfbtWJcfZUQlVAZLmFfROmJIA515kqz6lA L724/EUwZii0HWtWZPFRkGNfOB69DdXdqmARmYxPRSO13A==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=H3Zgya1kmsHIBG5JNBItWbbeNHT4NGyi6CsQRVK+1i0=; b=fIG5f27bgHPljaWGniQBpnQptf 85Yb9VUM/PGJPV6VBAJXdabC139RqHSR0IIs37CcpkKUSGOEY4WqLoRdQShjBpuRK80M3yn2+sNe8 clfFHI52h/VNr8gWJeKekM6D0yNgiF63xcgC0roLg5tc/jSzm8sw2y6YQObI3XP+kMX/n7HkzeEai srETZytZqrw3aOxa+UU63Gq6qPGv5EVU0jxXXgHwJ4KxFPKdBkLINpjXOF+Ovdu7e92noiQDWUY3Z 0MuG9kKvgDDXtSJFKMRhKU543afzQAoBJ/T772eWyzI7rGoCFK7D3YuSp3RSuGFdC1LC9NrSUa188 Go4G25Pw==; Received: from authenticated user by zero.zsh.org with local id 1kzqUt-000OKd-My; Thu, 14 Jan 2021 00:28:19 +0000 Authentication-Results: zsh.org; iprev=pass (mail-ua1-f52.google.com) smtp.remote-ip=209.85.222.52; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-ua1-f52.google.com ([209.85.222.52]:44341) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1kzqUc-000OAv-Cy; Thu, 14 Jan 2021 00:28:03 +0000 Received: by mail-ua1-f52.google.com with SMTP id a31so1264272uae.11 for ; Wed, 13 Jan 2021 16:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H3Zgya1kmsHIBG5JNBItWbbeNHT4NGyi6CsQRVK+1i0=; b=Vu2k9KqOE+rbxLs35/TwcJBYWa73AvDysPTq3voZdjGPFDcBwjNhJmrCzq17qclpxB Jr03/ds5K7Eprw7JRgZ9LQcQsIIolGHXkHBxVSUobi9Cdhg9t9+yryRCMGyBbDZM1lD1 FAM5ah0bOIAk2EcnoUQqu0rk5yJLCtmAHv8Nx8oqNQnClzBbdSl0VkFD5WRDxzaAJpCw DKl/5p26GW2HDSDdXL1axaM+luf7tvaCe3q4w0PQmx+n1oF74pfSev4HeO6Ut4A5WmEM nOcv965j7bY7rPT3wrrmjAQBxTaVNdqyc5EfdBTGEaQiYZkBITfGAqErVNcrSUkBSoM2 hAOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H3Zgya1kmsHIBG5JNBItWbbeNHT4NGyi6CsQRVK+1i0=; b=O4mGmMTRk3d3VyBAQLH5quq1cLh7RES4VlCP6wVSIRPvTPVCRHm+/s+i+/a/GdqQne BLGSUaGw6LWTSfJitrNo5QriorTZ6Ow4AowhorpoKboFXIkrgsU+/i/PeNE/NIqEGgCR vMOucPrwLj7ntHMFAXTCJ4+odN6jj49w3SSbqQWIDcT+Aj9Mrq1YTVmrW+dd0dgeAtJt owrY7cMCREPlnXzejLJ/Iqh+KKX2At0Fqg+CJpw7y26na5bBpfQ/qtJEy/5smw6rxtJd k+m3YBZGMn7tt7KJp/UzPymZV11SmlUJNr4AKAX3vFB+gtb7iW29/Z08g++wIGikUzVh HGsg== X-Gm-Message-State: AOAM531mcL1HGMj6w/2rR1699E4HW3T14uPfYXVCln/xBdaBb2paZysE oE2iDtQUdNE2bA+aoZe+n+BcFTtVVdkdnjVF0CFF4zBn X-Google-Smtp-Source: ABdhPJzL6FioyAGOEkueN0OjUb9WQlcmqw6uug9w1QOLwGo6AQFvRrDhBh4TI13FkCkWbFiZWDTwgBpqDu7wzWHcy30= X-Received: by 2002:a9f:2356:: with SMTP id 80mr4092726uae.92.1610584081337; Wed, 13 Jan 2021 16:28:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Devin Hussey Date: Wed, 13 Jan 2021 19:27:51 -0500 Message-ID: Subject: Re: [PATCH] Allow globbing with unreadable parent directories To: Bart Schaefer Cc: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="0000000000000c936b05b8d1540a" X-Seq: 47824 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: --0000000000000c936b05b8d1540a Content-Type: text/plain; charset="UTF-8" On Wed, Jan 13, 2021, 5:28 PM Bart Schaefer wrote: > On Tue, Jan 12, 2021 at 7:04 PM Devin Hussey > wrote: > > > > POSIX specifies that when globbing, parent directories only have to be > > searchable, not readable. > > > > + /* First check for search permission. */ > > + if (access(fn, X_OK) != 0) > > return; > > I don't think this is correct. Even if it is strictly correct per > POSIX (which would seem strange to me), it should not be applied in > zsh native mode (see my previous email about setopts). > > % mkdir /tmp/adirectory > % touch /tmp/adirectory/somefile > % chmod a-x /tmp/adirectory > % echo /tmp/adirectory/* > /tmp/adirectory/somefile > % echo /tmp/adirectory/*(.) > zsh: no match > > Lack of search permission only means that you can't tell what kind of > file "somefile" is (you can't read its inode data, e.g., stat() it), > not that you can't see the name itself. > This matches the behavior of the "pure" globber, POSIX, and literally every other shell. If we made it accept it unconditionally like my original solution, we would end up with the *opposite* issue, where CASE_GLOB would fail on files where NO_CASE_GLOB succeeds. Case insensitivity should not change the output due to file permissions. > + /* Then, if we have read permission, try to open the directory. */ > > + if (access(fn, R_OK) == 0) { > > + int dirs = !!q->next; > > + DIR *lock = opendir(fn); > > The access call here is redundant; opendir(fn) will fail if there is > not read permission. Why do you believe the extra test is needed? opendir(fn) will also fail if the "folder" is a file. However, you may be right, if the path is a file, the next access() will definitely fail, so I could remove that and only return if we can't access(fn, X_OK). I think the rest is just re-indentation. Did I miss an "else" clause > for the R_OK ? > Yes it is just reindentation. There is no else clause, it goes to the next section of the path if the current directory is unreadable. > Can you provide a specific test case that shows the difference in > behavior with and without this patch? I think I can throw something together, yes. As far as I can tell, the patch would only cause globbing to fail in more cases, not succeed where it > previously did not. > No, that is definitely not the case. opendir() would fail if either R_OK or X_OK was false, causing unreadable folders to be a false negative. This is allowing certain combinations where opendir() would fail. > --0000000000000c936b05b8d1540a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jan 13, 2021, 5:28 PM Bart Schaefer <schaefer@brasslantern.com> wr= ote:
On Tue, Jan 12, 2021 at 7:04 P= M Devin Hussey <husseydevin@gmail.com> wrote:
>
> POSIX specifies that when globbing, parent directories only have to be=
> searchable, not readable.
>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0/* First check for search permission. */ > +=C2=A0 =C2=A0 =C2=A0 =C2=A0if (access(fn, X_OK) !=3D 0)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return;

I don't think this is correct.=C2=A0 Even if it is strictly correct per=
POSIX (which would seem strange to me), it should not be applied in
zsh native mode (see my previous email about setopts).

% mkdir /tmp/adirectory
% touch /tmp/adirectory/somefile
% chmod a-x /tmp/adirectory
% echo /tmp/adirectory/*
/tmp/adirectory/somefile
% echo /tmp/adirectory/*(.)
zsh: no match

Lack of search permission only means that you can't tell what kind of file "somefile" is (you can't read its inode data, e.g., stat= () it),
not that you can't see the name itself.

This matches the behavior of the= "pure" globber, POSIX, and literally every other shell.=C2=A0

If we made it accept it un= conditionally like my original solution, we would end up with the *opposite= * issue, where CASE_GLOB would fail on files where NO_CASE_GLOB succeeds.

Case insensitivity should= not change the output due to file permissions.=C2=A0

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Then, if we have read per= mission, try to open the directory. */
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0if (access(fn, R_OK) =3D=3D 0) {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int dirs =3D !!q->next; > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DIR *lock =3D opendir(fn);
The access call here is redundant; opendir(fn) will fail if there is
not read permission.=C2=A0 Why do you believe the extra test is needed?

opendir(= fn) will also fail if the "folder" is a file.

However, you may be right, if the path is a= file, the next access() will definitely fail, so I could remove that and o= nly return if we can't access(fn, X_OK).

I think the rest is just re-indentation.=C2=A0 Did I miss an "else= " clause
for the R_OK ?

Yes it is just reindentation.
=

There is no else clause, it g= oes to the next section of the path if the current directory is unreadable.=


Can you provide a specific test case that shows the difference in
behavior with and without this patch?

I think I can throw something together, ye= s.

As far as I can tell, the patch
would only cause globbing to fail in more cases, not succeed where it
previously did not.

No, that is definitely not the case.

opendir() would fail if either R_OK or X_OK= was false, causing unreadable folders to be a false negative.=C2=A0
<= div dir=3D"auto">
This is allowing certain combi= nations where opendir() would fail.
--0000000000000c936b05b8d1540a--