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

[Junio C Hamano <gitster@pobox.com>]

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

> 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.