[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a2012ba2-e322-39e2-fa80-c8d4aef501de@samba.org>
Date: Mon, 9 Mar 2020 21:56:18 +0100
From: Stefan Metzmacher <metze@...ba.org>
To: David Howells <dhowells@...hat.com>, torvalds@...ux-foundation.org,
viro@...iv.linux.org.uk
Cc: Aleksa Sarai <cyphar@...har.com>, raven@...maw.net,
mszeredi@...hat.com, christian@...uner.io, jannh@...gle.com,
darrick.wong@...cle.com, kzak@...hat.com, jlayton@...hat.com,
linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/14] VFS: Add additional RESOLVE_* flags [ver #18]
Hi David,
> Add additional RESOLVE_* flags to correspond to AT_* flags that aren't
> currently implemented:
>
> RESOLVE_NO_TRAILING_SYMLINKS for AT_SYMLINK_NOFOLLOW
> RESOLVE_NO_TRAILING_AUTOMOUNTS for AT_NO_AUTOMOUNT
> RESOLVE_EMPTY_PATH for AT_EMPTY_PATH
Thanks for changing the names!
> This is necessary for fsinfo() to use RESOLVE_* flags instead of AT_* flags
> if the latter are to be considered deprecated for new system calls.
>
> Also make openat2() handle RESOLVE_NO_TRAILING_SYMLINKS.
>
> Automounting is currently forced by doing an open(), so adding support to
> openat2() for RESOLVE_NO_TRAILING_AUTOMOUNTS is not trivial.
lookup_flags &= ~LOOKUP_AUTOMOUNT won't work?
At least it should cause EINVAL (or something similar) instead of being
silently ignored. The same applies to RESOLVE_EMPTY_PATH, it should be
handled with some logic or also cause EINVAL.
vfs_statx()/vfs_stat_set_lookup_flags() seems to have a similar logic
using the AT_* flags.
metze
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists