linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <christian.brauner@ubuntu.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: David Howells <dhowells@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, 2 Mar 2020 13:35:10 +0100	[thread overview]
Message-ID: <20200302123510.bm3a2zssohwvkaa4@wittgenstein> (raw)
In-Reply-To: <20200302121959.it3iophjavbhtoyp@wittgenstein>

On Mon, Mar 02, 2020 at 01:20:00PM +0100, Christian Brauner wrote:
> On Mon, Mar 02, 2020 at 01:09:06PM +0100, Florian Weimer wrote:
> > * Christian Brauner:
> > 
> > >> But that's inconsistent with the rest of the system.  And for example,
> > >> if you make /etc/resolv.conf a symbolic link, a program which uses a new
> > >> I/O library (with the new interfaces) will not be able to read it.
> > >
> > > Fair, but I expect that e.g. a C library would simply implement openat()
> > > on top of openat2() if the latter is available and thus could simply
> > > pass RESOLVE_SYMLINKS so any new I/O library not making use of the
> > > syscall directly would simply get the old behavior. For anyone using the
> > > syscall directly they need to know about its exact semantics anyway. But
> > > again, maybe just having it opt-in is fine.
> > 
> > I'm more worried about fancy new libraries which go directly to the new
> > system calls, but set the wrong defaults for a general-purpose open
> > operation.
> > 
> > Can we pass RESOLVE_SYMLINKS with O_NOFLLOW, so that we can easily
> > implement open/openat for architectures that provide only the openat2
> > system call?
> 
> You can currently do RESOLVE_NO_SYMLINKS | O_NOFOLLOW. So I'd expect
> RESOLVE_SYMLINKS | O_NOFOLLOW would work as well. But from what it looks
> like having no symlink resolution be opt-in seems more likely.

One difference to openat() is that openat2() doesn't silently ignore
unknown flags. But I'm not sure that would matter for iplementing
openat() via openat2() since there are no flags that openat() knows about
that openat2() doesn't know about afaict. So the only risks would be
programs that accidently have a bit set that isn't used yet. But that
seems unlikely. And I'm not aware of any flag that was deprecated that
some programs could still pass (a problem we had with CLONE_DETACHED for
example).

  reply	other threads:[~2020-03-02 12:35 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 [this message]
2020-03-02 12:42             ` Florian Weimer
2020-03-02 12:55               ` Christian Brauner
     [not found]               ` <20200305141154.e246swv62rnctite@yavin>
2020-03-05 15:23                 ` Christian Brauner
2020-03-05 14:33             ` David Howells
2020-03-05 14:38               ` Florian Weimer
2020-03-05 14:43               ` David Howells
2020-03-02 14:27     ` David Howells
2020-03-02 14:35       ` Christian Brauner
2020-03-02 14:50       ` David Howells
2020-03-02 15:05         ` Christian Brauner
2020-03-02 15:24           ` Aleksa Sarai
2020-03-02 16:37           ` David Howells
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=20200302123510.bm3a2zssohwvkaa4@wittgenstein \
    --to=christian.brauner@ubuntu.com \
    --cc=cyphar@cyphar.com \
    --cc=dhowells@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).