All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Fairuzan Roslan <fairuzan.roslan@gmail.com>,
	gitster@pobox.com, git@vger.kernel.org, tboegi@web.de
Subject: Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
Date: Fri, 20 Feb 2015 11:40:08 +0100	[thread overview]
Message-ID: <vpqvbiwamt3.fsf@anie.imag.fr> (raw)
In-Reply-To: <20150219200833.GB5021@vauxhall.crustytoothpaste.net> (brian m. carlson's message of "Thu, 19 Feb 2015 20:08:33 +0000")

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> On Tue, Feb 17, 2015 at 09:51:38AM +0100, Matthieu Moy wrote:
>> This should be fixable from Git itself, by replacing the calls to
>> "unlink" with something like
>> 
>> int unlink_or_chmod(...) {
>> 	if (unlink(...)) {
>> 		chmod(...); // give user write permission
>> 		return unlink(...);
>> 	}
>> }
>> 
>> This does not add extra cost in the normal case, and would fix this
>> particular issue for afp shares. So, I think that would fix the biggest
>> problem for afp-share users without disturbing others. It seems
>> reasonable to me to do that unconditionnally.
>
> This can have security issues if you're trying to unlink a symlink, as 
> chmod will dereference the symlink but unlink will not.  Giving the file 
> owner write permission may not be sufficient, as the user may be a 
> member of a group with write access to the repo.  A malicious user who 
> also has access to the repo could force the current user to chmod an 
> arbitrary file such that it had looser permissions.

Ouch, indeed. I don't think that would be so problematic in practice (if
the attacker has access to the repo, it's easier to write arbitrary code
in hooks or config), but clearly we don't want to take the risk.

So, the right solution should be stg like Junio's

 * in init-db.c, autoprobe by doing something like this:

    create a test file with 0444 permission bits;
    if (unlink(that test file)) {
	chmod(that test file, 0644);
        if (!unlink(that test file)) {
		broken_unlink = 1;
		git_config_set("core.brokenunlink", broken_unlink);
	} else {
        	die("aaargh");
	}
    }

But when core.brokenunlink is set, just use 0666 instead of 0444 as
default mode for object files.

But right now, I'm not sure we're actually to work around an issue with
AFP shares or only one particular case of problematic configurtion for
one user.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

  reply	other threads:[~2015-02-20 10:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-16 17:54 odb_mkstemp's 0444 permission broke write/delete access on AFP Fairuzan Roslan
2015-02-16 18:23 ` Matthieu Moy
2015-02-16 18:41   ` Fairuzan Roslan
2015-02-16 19:08     ` Matthieu Moy
2015-02-17  3:22       ` Fairuzan Roslan
2015-02-17  5:34         ` Torsten Bögershausen
2015-02-17  5:54           ` Fairuzan Roslan
2015-02-17  8:51         ` Matthieu Moy
2015-02-17 16:58           ` Fairuzan Roslan
2015-02-17 17:54             ` Torsten Bögershausen
2015-02-18  8:15               ` Matthieu Moy
2015-02-18 13:47                 ` Fairuzan Roslan
2015-02-18 14:05                   ` Matthieu Moy
2015-02-18 14:23                     ` Fairuzan Roslan
2015-02-17 17:13           ` Junio C Hamano
2015-02-18 17:04             ` Matthieu Moy
2015-02-18 17:13               ` Junio C Hamano
2015-02-18 17:31                 ` Junio C Hamano
2015-02-19 20:08           ` brian m. carlson
2015-02-20 10:40             ` Matthieu Moy [this message]
2015-02-16 19:06   ` Junio C Hamano
2015-02-16 19:50     ` Torsten Bögershausen

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=vpqvbiwamt3.fsf@anie.imag.fr \
    --to=matthieu.moy@grenoble-inp.fr \
    --cc=fairuzan.roslan@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sandals@crustytoothpaste.net \
    --cc=tboegi@web.de \
    /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.