From: Aleksa Sarai <cyphar@cyphar.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com>,
linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk,
ptikhomirov@virtuozzo.com, linux-api@vger.kernel.org
Subject: Re: [PATCH] fs/open: add new RESOLVE_EMPTY_PATH flag for openat2
Date: Thu, 13 Jan 2022 01:43:31 +1100 [thread overview]
Message-ID: <20220112144331.dpbhi7j2vwutrxyt@senku> (raw)
In-Reply-To: <20220112143940.ugj27xzprmptqmr7@wittgenstein>
[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]
On 2022-01-12, Christian Brauner <christian.brauner@ubuntu.com> wrote:
> On Wed, Jan 12, 2022 at 12:02:17PM +0300, Andrey Zhadchenko wrote:
> > If you have an opened O_PATH file, currently there is no way to re-open
> > it with other flags with openat/openat2. As a workaround it is possible
> > to open it via /proc/self/fd/<X>, however
> > 1) You need to ensure that /proc exists
> > 2) You cannot use O_NOFOLLOW flag
> >
> > Both problems may look insignificant, but they are sensitive for CRIU.
>
> Not just CRIU. It's also an issue for systemd, LXD, and other users.
> (One old example is where we do need to sometimes stash an O_PATH fd to
> a /dev/pts/ptmx device and to actually perform an open on the device we
> reopen via /proc/<pid>/fd/<nr>.)
>
> > First of all, procfs may not be mounted in the namespace where we are
> > restoring the process. Secondly, if someone opens a file with O_NOFOLLOW
> > flag, it is exposed in /proc/pid/fdinfo/<X>. So CRIU must also open the
> > file with this flag during restore.
> >
> > This patch adds new constant RESOLVE_EMPTY_PATH for resolve field of
> > struct open_how and changes getname() call to getname_flags() to avoid
> > ENOENT for empty filenames.
>
> From my perspective this makes sense and is something that would be
> very useful instead of having to hack around this via procfs.
>
> However, e should consider adding RESOLVE_EMPTY_PATH since we already
> have AT_EMPTY_PATH. If we think this is workable we should try and reuse
> AT_EMPTY_PATH that keeps the api consistent with linkat(), readlinkat(),
> execveat(), statx(), open_tree(), mount_setattr() etc.
>
> If AT_EMPTY_PATH doesn't conflict with another O_* flag one could make
> openat() support it too?
I would much prefer O_EMPTYPATH, in fact I think this is what I called
it in my first draft ages ago. RESOLVE_ is meant to be related to
resolution restrictions, not changing the opening mode.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2022-01-12 14:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-12 9:02 [PATCH] fs/open: add new RESOLVE_EMPTY_PATH flag for openat2 Andrey Zhadchenko
2022-01-12 14:34 ` Aleksa Sarai
2022-01-12 14:51 ` Christian Brauner
2022-01-12 18:56 ` Andrey Zhadchenko
2022-01-13 6:46 ` Aleksa Sarai
2022-01-13 7:52 ` Andrey Zhadchenko
2022-01-14 4:24 ` Andrey Zhadchenko
2022-01-14 4:28 ` Aleksa Sarai
2022-01-17 6:35 ` Andrey Zhadchenko
2022-01-13 14:05 ` Christian Brauner
2022-01-13 14:44 ` Aleksa Sarai
2022-01-13 6:55 ` Aleksa Sarai
2022-01-12 14:39 ` Christian Brauner
2022-01-12 14:43 ` Aleksa Sarai [this message]
2022-01-12 14:53 ` Christian Brauner
2022-01-12 17:45 ` Andrey Zhadchenko
2022-01-13 6:47 ` Aleksa Sarai
2022-01-13 10:33 ` Christian Brauner
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=20220112144331.dpbhi7j2vwutrxyt@senku \
--to=cyphar@cyphar.com \
--cc=andrey.zhadchenko@virtuozzo.com \
--cc=christian.brauner@ubuntu.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ptikhomirov@virtuozzo.com \
--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