This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: [PATCH v2 0/3] Support opening a symlink with O_PATH | O_NOFOLLOW
- From: Ken Brown <kbrown at cornell dot edu>
- To: "cygwin-patches at cygwin dot com" <cygwin-patches at cygwin dot com>
- Date: Mon, 30 Dec 2019 21:47:40 +0000
- Subject: Re: [PATCH v2 0/3] Support opening a symlink with O_PATH | O_NOFOLLOW
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cornell.edu; dmarc=pass action=none header.from=cornell.edu; dkim=pass header.d=cornell.edu; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Af4XCYJLy0VsCmjfuDKMvIhQJJJii2TTj1vLw5uiQLQ=; b=FdyZ0NX3Fga8pUekHDIyb3tdAEwFRQRbG5JZXxMnEX/KbQ0wHnYhQRWERdPuwRlBNgk5HYTxcOKoSUkegtg/VLY4wT8QxQtB+tveZUGpaz2ZbN+eoxWwGL2VPWv5BE8gDjZIYicesyN8ADiRlTrfgeANZJfLWACIKxD0REiIRp2orrYFpqnZQaD8OQ/GL1RtlupnSErT2iSPu9NdGLl/K5cgEqFOp7TOV2767plhunjHb405pVYPeUiYHLZ2JFIEsUMQB9i/uoUORPPQJ+IRKWwIq9i9u+mUKTJ+gjo+/EvsJQ07LxZ8ptOuJUtFy4+9ERiFZc1SvsH4HBcbMAsEjw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EBVHMpx0MJRpgG3x2zh4sXS24uXiPAl2fTUJFzctIdBOFkIboGluSY2bbOYVZ4rwhc+0fCPLvGhVcK9ZYikCjicTBCSDxd3Kn0csU/YZyXpQXhiglYWcmMxva2It3ScHNY2cAnLcHtRgVlEgPLAkEETybSRfGIFTFrBBdB1XffkfZm+krA6gps5X84vQmGIv8GNQE+wjTbzwgRACfrNlUTieF5Hlz08gyrQHpzZz2h1gQZLptLEmUmRKnxXCgEJHYs1Pxs/LX1sGdnoHkWcSVWawwY5OAb3uREvJQmFpyNWApgyoq0f3NmWqIYu3pZcnqJgGoWy6CkhHwc1Uus0QnQ==
- References: <20191229175637.1050-1-kbrown@cornell.edu> <d88c5dee-9457-3c39-960c-ea07842cd0c5@SystematicSw.ab.ca> <aafbc75d-11db-0faf-6e13-72681c5784a3@cornell.edu> <f964457b-9d33-a252-3cc9-e035a4fe1c1a@SystematicSw.ab.ca>
On 12/30/2019 3:55 PM, Brian Inglis wrote:
> On 2019-12-30 12:53, Ken Brown wrote:
>> On 12/30/2019 2:18 PM, Brian Inglis wrote:
>>> On 2019-12-29 10:56, Ken Brown wrote:
>>>> Currently, opening a symlink with O_NOFOLLOW fails with ELOOP.
>>>> Following Linux, the first patch in this series allows the call to
>>>> succeed if O_PATH is also specified.
>>>>
>>>> According to the Linux man page for 'open', the file descriptor
>>>> returned by the call should be usable as the dirfd argument in calls
>>>> to fstatat and readlinkat with an empty pathname, to have
>>>> the calls operate on the symbolic link. The second and third patches
>>>> achieve this. For fstatat, we do this by adding support
>>>> for the AT_EMPTY_PATH flag.
>>>>
>>>> Note: The man page mentions fchownat and linkat also. linkat already
>>>> supports the AT_EMPTY_PATH flag, so nothing needs to be done. But I
>>>> don't understand how this could work for fchownat, because fchown
>>>> fails with EBADF if its fd argument was opened with O_PATH. So I
>>>> haven't touched fchownat.
>>>>
>>>> Am I missing something?
>>>
>>> WSL $ man 2 chown
>>> ...
>>> "AT_EMPTY_PATH (since Linux 2.6.39)
>>> If pathname is an empty string, operate on the file referred to
>>> by dirfd (which may have been obtained using the open(2) O_PATH
>>> flag). In this case, dirfd can refer to any type of file, not
>>> just a directory. If dirfd is AT_FDCWD, the call operates on
>>> the current working directory. This flag is Linux-specific; de‐
>>> fine _GNU_SOURCE to obtain its definition."
>>>
>>> says chown the dirfd, regardless of what it is,
>>> except if AT_FDCWD, chown the CWD.
>>>
>>> WSL $ man 2 open
>>> "O_PATH (since Linux 2.6.39)
>>> Obtain a file descriptor that can be used for two purposes: to
>>> indicate a location in the filesystem tree and to perform
>>> operations that act purely at the file descriptor level. The
>>> file itself is not opened, and other file operations (e.g.,
>>> read(2), write(2), fchmod(2), fchown(2), fgetxattr(2),
>>> ioctl(2), mmap(2)) fail with the error EBADF."
>>>
>>> O_PATH does not open the file, so fchown returns EBADF,
>>> as it requires an fd of an open file.
>>
>> I think you've just confirmed what I already said: If fchownat is called with
>> AT_EMPTY_PATH, with an empty pathname, and with dirfd referring to a file that
>> was opened with O_PATH, then fchownat will fail with EBADF.
>>
>> So for the purposes of this patch series, I don't see the point of adding
>> support for AT_EMPTY_PATH in fchownat.
>>
>> Am I missing something?
>
> That is the user's problem: it is their responsibility to pass an fd open for
> reading or searching, not one opened with O_PATH (on Linux or Cygwin), or
> AT_FDCWD; it is Cygwin's responsibility to ensure that valid args succeed and
> invalid args return the expected errno.
Yes, but Cygwin doesn't claim to support the AT_EMPTY_PATH flag except in
linkat. So there is no expected errno. The only way there would be an expected
errno is if we decide to add support for AT_EMPTY_PATH to fchownat. I'm saying
that I don't see the point in doing that, and I'm asking whether I'm missing
something. If you think I should add that support, please explain why.
Ken