From: Florian Weimer <fweimer@redhat.com>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-api@vger.kernel.org, Eric Sandeen <sandeen@sandeen.net>
Subject: Re: [PATCH] vfs: add faccessat2 syscall
Date: Thu, 16 Apr 2020 16:43:40 +0200 [thread overview]
Message-ID: <87a73bcwyr.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20200416143532.11743-1-mszeredi@redhat.com> (Miklos Szeredi's message of "Thu, 16 Apr 2020 16:35:32 +0200")
* Miklos Szeredi:
> POSIX defines faccessat() as having a fourth "flags" argument, while the
> linux syscall doesn't have it. Glibc tries to emulate AT_EACCESS and
> AT_SYMLINK_NOFOLLOW, but AT_EACCESS emulation is broken.
>
> Add a new faccessat(2) syscall with the added flags argument and implement
> both flags.
>
> The value of AT_EACCESS is defined in glibc headers to be the same as
> AT_REMOVEDIR. Use this value for the kernel interface as well, together
> with the explanatory comment.
Thanks a lot for this!
> +long do_faccessat(int dfd, const char __user *filename, int mode, int flags)
> +{
> + const struct cred *old_cred = NULL;
> + struct path path;
> + struct inode *inode;
> + int res;
> + unsigned int lookup_flags = LOOKUP_FOLLOW;
> +
> + if (mode & ~S_IRWXO) /* where's F_OK, X_OK, W_OK, R_OK? */
> + return -EINVAL;
> +
> + if (flags & ~(AT_EACCESS | AT_SYMLINK_NOFOLLOW))
> + return -EINVAL;
Should this accept AT_EMPTY_PATH as well?
(I can't comment on the rest of the logic of the patch.)
> diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
> index ca88b7bce553..2f86b2ad6d7e 100644
> --- a/include/uapi/linux/fcntl.h
> +++ b/include/uapi/linux/fcntl.h
> @@ -84,10 +84,20 @@
> #define DN_ATTRIB 0x00000020 /* File changed attibutes */
> #define DN_MULTISHOT 0x80000000 /* Don't remove notifier */
>
> +/*
> + * The constants AT_REMOVEDIR and AT_EACCESS have the same value. AT_EACCESS is
> + * meaningful only to faccessat, while AT_REMOVEDIR is meaningful only to
> + * unlinkat. The two functions do completely different things and therefore,
> + * the flags can be allowed to overlap. For example, passing AT_REMOVEDIR to
> + * faccessat would be undefined behavior and thus treating it equivalent to
> + * AT_EACCESS is valid undefined behavior.
> + */
> #define AT_FDCWD -100 /* Special value used to indicate
> openat should use the current
> working directory. */
> #define AT_SYMLINK_NOFOLLOW 0x100 /* Do not follow symbolic links. */
> +#define AT_EACCESS 0x200 /* Test access permitted for
> + effective IDs, not real IDs. */
> #define AT_REMOVEDIR 0x200 /* Remove directory instead of
> unlinking file. */
> #define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */
I can confirm that this is what glibc does, ofr better or worse.
Thanks,
Florian
next prev parent reply other threads:[~2020-04-16 14:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-16 14:35 [PATCH] vfs: add faccessat2 syscall Miklos Szeredi
2020-04-16 14:43 ` Florian Weimer [this message]
2020-04-18 18:36 ` Stefan Metzmacher
2020-04-18 19:00 ` Miklos Szeredi
2020-04-18 20:22 ` Stefan Metzmacher
2020-04-20 8:58 ` Miklos Szeredi
2020-04-20 9:03 ` Stefan Metzmacher
2020-04-19 9:56 ` 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=87a73bcwyr.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mszeredi@redhat.com \
--cc=sandeen@sandeen.net \
--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.