Re: [RFC] Secure central repositories by UNIX socket authentication

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 27, 2008, 22:56 UTC
Message-ID: <7vsl0ix4gh.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080127103934.GA2735@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

Show 8 quoted lines

> This isn't anywhere near ready for application, but I'm floating
> it out there to see what people think.  Its a cool new feature that
> will certainly *not* be in 1.5.4.  :-)
>
> In a central repository configuration users may not have access
> to write new objects into a Git repository, or to edit the refs,
> especially if the repository is being protected by an update hook
> (e.g. contrib/hooks/updated-paranoid).

Sorry, but I am puzzled about what this assumption is trying to achieve here.

If the configuration is based on central repository model, wouldn't the users who are participating in the project have write access to the repository by being in the project's group and the repository initialized with core.sharedrepository=true?

> This change allows any repository owner to setup a git-daemon
> that other users on the same host can connect through to perform
> upload-pack or receive-pack.

My reading of this is that it creates a backdoor for people who cannot (either "are not allowed to", or "cannot be bothered to") create and maintain project specific access control by the traditional means of filesystem access control based on user groups, by allowing others to run controlled stuff under the repository owner's uid. In addition to having to worry about the in-repo data properly being protected from people outside the group, you now need to worry about the access through that backdoor does not extend outside of the repository. E.g. the repository owner's $HOME that is outside the repository would be writable that owner, but is not meant to be accessible by project participants. If you allow others to "run as" you, the only thing that forbids that process running as you from accessing $HOME is an additional audit of git-daemon and the programs it spawns.

In short, my initial reaction to this is not very supportive, not because of the way it is coded but because of its security design.

But I may probably have misread the intention.