On 03/09/2014 10:57 PM, Julian Brost wrote:
On 07.03.2014 22:04, Jeff King wrote:
Yes, this is a well-known issue. The only safe operation on a
repository for which somebody else controls hooks and config is to
fetch from it (upload-pack on the remote repository does not
respect any dangerous config or hooks).

I'm a little bit surprised that you and some other people I asked see
this as such a low-priority problem as this makes social engineering
attacks on multi-user systems, like they are common at universities,
really easy (this is also how I noticed the problem).

This, and a lot more control related issues, are solved by tools like
gitolite (which I maintain) and Gerrit (from Google), and also many GUI
based access control tools like gitlab, gitorious, etc.

In these schemes the user does not have a "unix" account on the server,
and any hooks that run will run as the "hosting user".  Access is either
via ssh pub keys (most commonly) or http auth.

It is my belief that most multi-user systems have installed one of these
systems, and therefore the situation you speak of does not arise.  They
probably didn't install them to solve *this* problem, but to keep some
semblance of control over who can access what repo, but as a side-effect
they solve this problem also.


It has been discussed, but nobody has produced patches. I think
that nobody is really interested in doing so because:

1. It introduces complications into previously-working setups
(e.g., a daemon running as "nobody" serving repos owned by a "git"
user needs to mark "git" as trusted).

2. In most cases, cross-server boundaries provide sufficient
insulation (e.g., I might not push to an evil person's repo, but
rather to a shared repo whose hooks and config are controlled by
root on the remote server).

If you want to work on it, I think it's an interesting area. But
any development would need to think about the transition plan for
existing sites that will be broken.

I can understand the problem with backward compatibility but in my
opinion the default behavior should definitely be to ignore untrusted
config files and hooks as it would otherwise only protect users that
are already aware of the issue anyways and manually enable this option.

Are there any plans for some major release in the future that would
allow introducing backward incompatible changes?

I would definitely spend some time working on a patch but so far I
have no idea of git's internals and never looked at the source before.

At the very least, the current trust model could stand to be
documented much better (I do not think the rule of "fetching is
safe, everything else is not" is mentioned anywhere explicitly).

Good point but not enough in my opinion as I haven't read every git
manpage before running it for the first time.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to