From: David Howells <dhowells@redhat.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: dhowells@redhat.com, Florian Weimer <fweimer@redhat.com>,
linux-api@vger.kernel.org, viro@zeniv.linux.org.uk,
metze@samba.org, torvalds@linux-foundation.org,
cyphar@cyphar.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: Have RESOLVE_* flags superseded AT_* flags for new syscalls?
Date: Mon, 02 Mar 2020 14:50:03 +0000 [thread overview]
Message-ID: <888183.1583160603@warthog.procyon.org.uk> (raw)
In-Reply-To: <20200302143546.srzk3rnh4o6s76a7@wittgenstein>
Christian Brauner <christian.brauner@ubuntu.com> wrote:
> I think we settled this and can agree on RESOLVE_NO_SYMLINKS being the
> right thing to do, i.e. not resolving symlinks will stay opt-in.
> Or is your worry even with the current semantics of openat2()? I don't
> see the issue since O_NOFOLLOW still works with openat2().
Say, for example, my home dir is on a network volume somewhere and /home has a
symlink pointing to it. RESOLVE_NO_SYMLINKS cannot be used to access a file
inside my homedir if the pathwalk would go through /home/dhowells - this would
affect fsinfo() - so RESOLVE_NO_SYMLINKS is not a substitute for
AT_SYMLINK_NOFOLLOW (O_NOFOLLOW would not come into it).
David
next prev parent reply other threads:[~2020-03-02 14:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-28 14:53 Have RESOLVE_* flags superseded AT_* flags for new syscalls? David Howells
2020-02-28 15:24 ` Christian Brauner
2020-02-29 15:26 ` Aleksa Sarai
2020-02-29 15:54 ` Aleksa Sarai
2020-03-01 16:46 ` Christian Brauner
2020-03-01 16:38 ` Christian Brauner
2020-03-02 11:30 ` Florian Weimer
2020-03-02 11:52 ` Christian Brauner
2020-03-02 12:05 ` Christian Brauner
2020-03-02 15:10 ` Christian Brauner
2020-03-02 15:36 ` Aleksa Sarai
2020-03-02 16:31 ` Christian Brauner
2020-03-02 12:09 ` Florian Weimer
2020-03-02 12:19 ` Christian Brauner
2020-03-02 12:35 ` Christian Brauner
2020-03-02 12:42 ` Florian Weimer
2020-03-02 12:55 ` Christian Brauner
2020-03-05 14:33 ` David Howells
2020-03-05 14:38 ` Florian Weimer
2020-03-05 14:43 ` David Howells
[not found] ` <20200305141154.e246swv62rnctite@yavin>
2020-03-05 15:23 ` Christian Brauner
2020-03-02 14:27 ` David Howells
2020-03-02 14:35 ` Christian Brauner
2020-03-02 14:50 ` David Howells [this message]
2020-03-02 15:05 ` Christian Brauner
2020-03-02 15:24 ` Aleksa Sarai
2020-03-02 16:37 ` David Howells
[not found] ` <20200306140032.tpwfytofaeuazalo@yavin>
2020-03-06 14:48 ` David Howells
2020-03-02 15:10 ` Aleksa Sarai
2020-03-02 15:23 ` David Howells
2020-03-02 14:30 ` David Howells
2020-03-02 15:04 ` Aleksa Sarai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=888183.1583160603@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=christian.brauner@ubuntu.com \
--cc=cyphar@cyphar.com \
--cc=fweimer@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=metze@samba.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.