* [PATCH] fcntl.h: define AT_EACCESS @ 2010-04-16 3:08 maximilian attems 2010-04-19 21:47 ` Andrew Morton 0 siblings, 1 reply; 6+ messages in thread From: maximilian attems @ 2010-04-16 3:08 UTC (permalink / raw) To: Linus Torvalds Cc: linux-kernel, maximilian attems, stable, Ulrich Drepper, H. Peter Anvin, Herbert Xu 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: stable@kernel.org Cc: Ulrich Drepper <drepper@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: maximilian attems <max@stro.at> --- 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] fcntl.h: define AT_EACCESS 2010-04-16 3:08 [PATCH] fcntl.h: define AT_EACCESS maximilian attems @ 2010-04-19 21:47 ` Andrew Morton 2010-04-19 21:57 ` maximilian attems 0 siblings, 1 reply; 6+ messages in thread From: Andrew Morton @ 2010-04-19 21:47 UTC (permalink / raw) To: maximilian attems Cc: Linus Torvalds, linux-kernel, stable, Ulrich Drepper, H. Peter Anvin, Herbert Xu On Fri, 16 Apr 2010 05:08:00 +0200 maximilian attems <max@stro.at> 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: stable@kernel.org > Cc: Ulrich Drepper <drepper@redhat.com> > Cc: H. Peter Anvin <hpa@zytor.com> > Cc: Herbert Xu <herbert@gondor.apana.org.au> > Signed-off-by: maximilian attems <max@stro.at> > --- > 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fcntl.h: define AT_EACCESS 2010-04-19 21:47 ` Andrew Morton @ 2010-04-19 21:57 ` maximilian attems 2010-04-19 22:10 ` Ulrich Drepper 2010-04-19 22:20 ` David Wagner 0 siblings, 2 replies; 6+ messages in thread From: maximilian attems @ 2010-04-19 21:57 UTC (permalink / raw) To: Andrew Morton Cc: Linus Torvalds, linux-kernel, stable, Ulrich Drepper, H. Peter Anvin, Herbert Xu On Mon, Apr 19, 2010 at 02:47:29PM -0700, Andrew Morton wrote: > On Fri, 16 Apr 2010 05:08:00 +0200 > maximilian attems <max@stro.at> 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: stable@kernel.org > > Cc: Ulrich Drepper <drepper@redhat.com> > > Cc: H. Peter Anvin <hpa@zytor.com> > > Cc: Herbert Xu <herbert@gondor.apana.org.au> > > Signed-off-by: maximilian attems <max@stro.at> > > --- > > 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 */ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fcntl.h: define AT_EACCESS 2010-04-19 21:57 ` maximilian attems @ 2010-04-19 22:10 ` Ulrich Drepper 2010-04-19 22:11 ` H. Peter Anvin 2010-04-19 22:20 ` David Wagner 1 sibling, 1 reply; 6+ messages in thread From: Ulrich Drepper @ 2010-04-19 22:10 UTC (permalink / raw) To: maximilian attems Cc: Andrew Morton, Linus Torvalds, linux-kernel, stable, H. Peter Anvin, Herbert Xu -----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----- ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fcntl.h: define AT_EACCESS 2010-04-19 22:10 ` Ulrich Drepper @ 2010-04-19 22:11 ` H. Peter Anvin 0 siblings, 0 replies; 6+ messages in thread From: H. Peter Anvin @ 2010-04-19 22:11 UTC (permalink / raw) To: Ulrich Drepper Cc: maximilian attems, Andrew Morton, Linus Torvalds, linux-kernel, stable, Herbert Xu 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fcntl.h: define AT_EACCESS 2010-04-19 21:57 ` maximilian attems 2010-04-19 22:10 ` Ulrich Drepper @ 2010-04-19 22:20 ` David Wagner 1 sibling, 0 replies; 6+ messages in thread From: David Wagner @ 2010-04-19 22:20 UTC (permalink / raw) To: linux-kernel 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()? ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-04-19 22:28 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-16 3:08 [PATCH] fcntl.h: define AT_EACCESS maximilian attems 2010-04-19 21:47 ` Andrew Morton 2010-04-19 21:57 ` maximilian attems 2010-04-19 22:10 ` Ulrich Drepper 2010-04-19 22:11 ` H. Peter Anvin 2010-04-19 22:20 ` David Wagner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox