noticed on a klibc build of dash that someone had left out that def:
usr/dash/bltin/test.c:490: error: ‘AT_EACCESS’ undeclared (first use in thiction)
Cc: [email protected]
Cc: Ulrich Drepper <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Herbert Xu <[email protected]>
Signed-off-by: maximilian attems <[email protected]>
---
include/linux/fcntl.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
index 8603740..8bb001d 100644
--- a/include/linux/fcntl.h
+++ b/include/linux/fcntl.h
@@ -39,6 +39,8 @@
#define AT_REMOVEDIR 0x200 /* Remove directory instead of
unlinking file. */
#define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */
+#define AT_EACCESS 0x200 /* Test access permitted for
+ effective IDs, not real IDs. */
#ifdef __KERNEL__
--
1.7.0.4
On Fri, 16 Apr 2010 05:08:00 +0200
maximilian attems <[email protected]> wrote:
> noticed on a klibc build of dash that someone had left out that def:
> usr/dash/bltin/test.c:490: error: ___AT_EACCESS___ undeclared (first use in thiction)
>
> Cc: [email protected]
> Cc: Ulrich Drepper <[email protected]>
> Cc: H. Peter Anvin <[email protected]>
> Cc: Herbert Xu <[email protected]>
> Signed-off-by: maximilian attems <[email protected]>
> ---
> include/linux/fcntl.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
> index 8603740..8bb001d 100644
> --- a/include/linux/fcntl.h
> +++ b/include/linux/fcntl.h
> @@ -39,6 +39,8 @@
> #define AT_REMOVEDIR 0x200 /* Remove directory instead of
> unlinking file. */
> #define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */
> +#define AT_EACCESS 0x200 /* Test access permitted for
> + effective IDs, not real IDs. */
>
I'm all confused.
The affects sys_faccesat(), yes? But sys_faccesat() never gets passed
a `flags' argument so how does the behaviour which the FACCESSAT(2)
manpage describes get implemented?
This patch doesn't actually change kernel behaviour, so how can setting
AT_EACCESS change any syscall's actions?
It's a bit of a worry that the proposed value for AT_EACCESS duplicates
AT_REMOVEDIR. I guess that, despite apeparances, they're different
namespaces. Any thoughts on the implications of this?
On Mon, Apr 19, 2010 at 02:47:29PM -0700, Andrew Morton wrote:
> On Fri, 16 Apr 2010 05:08:00 +0200
> maximilian attems <[email protected]> wrote:
>
> > noticed on a klibc build of dash that someone had left out that def:
> > usr/dash/bltin/test.c:490: error: ___AT_EACCESS___ undeclared (first use in thiction)
> >
> > Cc: [email protected]
> > Cc: Ulrich Drepper <[email protected]>
> > Cc: H. Peter Anvin <[email protected]>
> > Cc: Herbert Xu <[email protected]>
> > Signed-off-by: maximilian attems <[email protected]>
> > ---
> > include/linux/fcntl.h | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
> > index 8603740..8bb001d 100644
> > --- a/include/linux/fcntl.h
> > +++ b/include/linux/fcntl.h
> > @@ -39,6 +39,8 @@
> > #define AT_REMOVEDIR 0x200 /* Remove directory instead of
> > unlinking file. */
> > #define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */
> > +#define AT_EACCESS 0x200 /* Test access permitted for
> > + effective IDs, not real IDs. */
> >
>
> I'm all confused.
>
> The affects sys_faccesat(), yes? But sys_faccesat() never gets passed
> a `flags' argument so how does the behaviour which the FACCESSAT(2)
> manpage describes get implemented?
>
> This patch doesn't actually change kernel behaviour, so how can setting
> AT_EACCESS change any syscall's actions?
>
> It's a bit of a worry that the proposed value for AT_EACCESS duplicates
> AT_REMOVEDIR. I guess that, despite apeparances, they're different
> namespaces. Any thoughts on the implications of this?
glibc fcntl.h defines AT_EACCESS in the same way as aboves patch,
concerning the implementation, others should know better.
the dash code calling faccessat has the 4 params,
klibc faccessat had only 3 args, guess nobody had used it before.
the relevant dash code reads:
#ifdef HAVE_FACCESSAT
static int test_file_access(const char *path, int mode)
{
return !faccessat(AT_FDCWD, path, mode, AT_EACCESS);
}
#else /* HAVE_FACCESSAT */
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/19/2010 02:57 PM, maximilian attems wrote:
> the dash code calling faccessat has the 4 params,
> klibc faccessat had only 3 args, guess nobody had used it before.
The function is implemented at userlevel. The kernel code has the same
name but isn't a complete implementation. There is no point in defining
the symbol in the kernel headers.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkvM1L0ACgkQ2ijCOnn/RHS1zgCggyyqLkOWD7dyOeLOiC314niu
+MYAoKQVKnG3DSZii9lodwvIHkBIppEF
=y6bR
-----END PGP SIGNATURE-----
On 04/19/2010 03:10 PM, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/19/2010 02:57 PM, maximilian attems wrote:
>> the dash code calling faccessat has the 4 params,
>> klibc faccessat had only 3 args, guess nobody had used it before.
>
> The function is implemented at userlevel. The kernel code has the same
> name but isn't a complete implementation. There is no point in defining
> the symbol in the kernel headers.
>
They should be added as a comment, at least, to avoid future conflicts.
-hpa
Can you share some justification why it's worth extending
faccessat() with new options?
Isn't faccessat() insecure in most use cases, due to TOCTTOU
(time-of-check to time-of-use) vulnerabilities? When faccessat()
returns 0, you learn that at some point in the past, the process had
permission to access a given file, though the process may or may not
have permission at the moment. Why is that a useful thing to know?
I'm sure you're familiar with all the standard arguments why using
access() tends to represent a security vulnerability. Is there a reason
why similar arguments do not apply to faccessat()?