All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	"W. Trevor King" <wking@tremily.us>,
	Mike Galbraith <bitbucket@online.de>, git <git@vger.kernel.org>
Subject: [PATCH] fixup! config: allow inaccessible configuration under $HOME
Date: Fri, 12 Apr 2013 13:34:42 -0700	[thread overview]
Message-ID: <20130412203442.GT27070@google.com> (raw)
In-Reply-To: <20130412193755.GA5329@sigill.intra.peff.net>

A cleanup from Jeff King.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 wrapper.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

Jeff King wrote:

> I kind of wonder if we are doing anything with the check at this point.
> I suppose ENOMEM and EIO are the only interesting things left at this
> point. The resulting code would be much nicer if the patch were just:
>
>   -access_or_die(...);
>   +access(...);
>
> but I guess those conditions are still worth checking for, especially if
> we think an attacker could trigger ENOMEM intentionally. To be honest, I
> am not sure how possible that is, but it is not that hard to do so.

Yeah, I was tempted to go the plain access() route.  The case that
convinced me not to is that I wouldn't want to think about whether
there could have been a blip in $HOME producing EIO when wondering how
some malformed object had been accepted.  The ENOMEM case just seemed
simpler to explain.

I would also be surprised if it is easy to control kernel ENOMEM
carefully enough to exploit (a more likely DoS outcome is crashing
programs or a kernel assertion failure, which are more harmless in
their way).  I've given up on predicting what is too hard or easy
enough for security folks.  I couldn't think of an obviously easier
vulnerability that is already accepted to put my mind at ease.

[...]
> I know you are trying to be flexible with the flag,

I was mostly worried about damage to readability if we end up needing
to go further down this direction.  The opportunity to look at all
call sites was also nice.

[...]
>   static int access_error_is_ok(int err, int flag)
>   {
>           return err == ENOENT || errno == ENOTDIR ||
>                   (flag & ACCESS_EACCES_OK && err == EACCES);
>   }

Nice.  Here's a patch for squashing in.

diff --git a/wrapper.c b/wrapper.c
index e860ad1..29a866b 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -408,11 +408,16 @@ void warn_on_inaccessible(const char *path)
 	warning(_("unable to access '%s': %s"), path, strerror(errno));
 }
 
+static int access_error_is_ok(int err, unsigned flag)
+{
+	return errno == ENOENT || errno == ENOTDIR ||
+		((flag & ACCESS_EACCES_OK) && errno == EACCES);
+}
+
 int access_or_warn(const char *path, int mode, unsigned flag)
 {
 	int ret = access(path, mode);
-	if (ret && errno != ENOENT && errno != ENOTDIR &&
-	    (!(flag & ACCESS_EACCES_OK) || errno != EACCES))
+	if (ret && !access_error_is_ok(errno, flag))
 		warn_on_inaccessible(path);
 	return ret;
 }
@@ -420,8 +425,7 @@ int access_or_warn(const char *path, int mode, unsigned flag)
 int access_or_die(const char *path, int mode, unsigned flag)
 {
 	int ret = access(path, mode);
-	if (ret && errno != ENOENT && errno != ENOTDIR &&
-	    (!(flag & ACCESS_EACCES_OK) || errno != EACCES))
+	if (ret && !access_error_is_ok(errno, flag))
 		die_errno(_("unable to access '%s'"), path);
 	return ret;
 }
-- 
1.8.2.1

  reply	other threads:[~2013-04-12 20:34 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-10  5:33 regression: "96b9e0e3 config: treat user and xdg config permission problems as errors" busted git-daemon Mike Galbraith
2013-04-10 13:56 ` W. Trevor King
2013-04-11  3:39   ` Mike Galbraith
2013-04-11  5:42     ` Jeff King
2013-04-11  7:59       ` Mike Galbraith
2013-04-11 15:35       ` Junio C Hamano
2013-04-11 17:24         ` Jeff King
2013-04-11 18:11           ` Jonathan Nieder
2013-04-11 18:14             ` Jeff King
2013-04-11 18:25               ` Jonathan Nieder
2013-04-11 19:54               ` Junio C Hamano
2013-04-11 20:03                 ` W. Trevor King
2013-04-11 22:20                   ` Junio C Hamano
2013-04-11 22:23                     ` Jeff King
2013-04-12  0:57                       ` W. Trevor King
2013-04-12  4:11                         ` Junio C Hamano
2013-04-12  4:35                           ` Jeff King
2013-04-12  4:46                             ` Junio C Hamano
2013-04-12  5:05                               ` Jeff King
2013-04-12  5:46                                 ` Mike Galbraith
2013-04-12 11:26                                 ` W. Trevor King
2013-04-12 14:48                                   ` Jeff King
2013-04-12 16:08                                     ` Junio C Hamano
2013-04-12 16:16                                       ` Jeff King
2013-04-12 17:05                                         ` Jeff King
2013-04-12 18:23                                           ` Junio C Hamano
2013-04-12 19:01                                             ` Jeff King
2013-04-12 19:51                                               ` Junio C Hamano
2013-04-12 19:58                                                 ` Jeff King
2013-04-12 20:45                                                   ` Junio C Hamano
2013-04-12 19:14                                           ` [PATCH] config: allow inaccessible configuration under $HOME Jonathan Nieder
2013-04-12 19:37                                             ` Jeff King
2013-04-12 20:34                                               ` Jonathan Nieder [this message]
2013-04-12 21:03                                                 ` [PATCH v2] " Jonathan Nieder
2013-04-13  4:28                                                   ` Mike Galbraith
2013-05-25 11:35                                                   ` Jason A. Donenfeld
2013-04-12 17:31                                         ` regression: "96b9e0e3 config: treat user and xdg config permission problems as errors" busted git-daemon Junio C Hamano
2013-04-12 16:21                                       ` Mike Galbraith
2013-04-11 20:08                 ` Jeff King

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=20130412203442.GT27070@google.com \
    --to=jrnieder@gmail.com \
    --cc=bitbucket@online.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=wking@tremily.us \
    /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.