This is the mail archive of the
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 19:53:23 +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=eX35+WUxQWPDQIKKAr6Q1ebgqDCP93O3f8JA44Kf97A=; b=L01zxlo/tLZsu8WDyCnv2C4QYepVDlkX1VnabYHAKTsyGMudAz41RjznAalVua71XiQsizLhOMC4tL/EIDk4bWIppgnmT9fei7Dr/40RrFxJY/I3IaLSaCXG9wZNqF8rsag+p0mHndwuYME4vXzCdLXWxzCxkmZDM9hAA+n2bkRnDbY0C97QtHfnjx+8foD3eTCMRbJ7vqCCRuYgdVfuWinGdrQ1HMDPMBfvpwq+SgJTmERg8aMmy7ktClwzD8hME2KwED7iuWvfRuOeQGDIDZQKHz5NQzUyXFfpzAmiGb9kjKY/MR+EcbJBTJ0j7/oxUnn8ZLynfMcvg+oj/7Ag6g==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CfzV1gUii6e8iDm82QD1EooGX0tRoCN3M2/S5rY9rB3gFz5GDnuBgp4xim8ZbRGZBAur4n3uGnkfXCUWpaQQbF9RqmOfCZH0v4/OorawS3kpN9DBWZxSpLBYg2n+8uMCAoGiqUZ3aFY49HJuPJVsX9oE3e2eHz2SJisP9J+uJkMBsDTp5rXlln8ga57bRUgEi7ahaF1D6KsvOMs9YtjhhfvJgEUbsR4bngZyE3AF0IjOmUlzVPvaRsds82xXOPkNR3SWdN8vPJ4Z0zPdTXON9+hpfcmzRJTo4Qc1ArfFYBsFXkILst5YnHgkUe3NM09hMGK4ne9Io8t0PEp6Uxt/ag==
- References: <email@example.com> <d88c5dee-9457-3c39-960c-ea07842cd0c5@SystematicSw.ab.ca>
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?