"Shawn O. Pearce" [off-list ref] 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.
Junio C Hamano [off-list ref] wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
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
[...]
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.
So you are partially suggesting that git-daemon isn't thought to
be secure, and that anything readable by the user that git-daemon
is running as is fully exposed to the public Internet. So the
access control attempts relating to --base-path or the check for
git-daemon-export-ok shouldn't really be trusted or relied upon.
If that really is the case, perhaps git-daemon should be audited
and hardened further. Last I checked, we encouraged people to run
it to offer anonymous access to repositories, and the documentation
suggests there are publishing access controls that actually work.
If those controls cannot be trusted then we shouldn't encourage
running git-daemon on untrusted networks.
With regards to this patch, yes, you can export your entire $HOME
and maybe expose things you shouldn't or didn't want to. But even
without git installed you could do this:
cp /bin/bash /tmp/be-like-mike
chown $USER /tmp/be-like-mike
chmod 777 /tmp/be-like-mike
chmod u+s /tmp/be-like-mike
wall "try out /tmp/be-like-mike today"
but why would anyone do something that foolish? UNIX provides the
tools to do this, because there are cases where it can be useful,
but really, you have to be nuts to export all of $HOME.
--
Shawn.
Junio C Hamano [off-list ref] wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
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?
Hmm. core.sharedrepository is sometimes a bad solution.
core.sharedrepository means I need to give write access to both the
refs database and the object database to all members of the project.
Some of whom may not be able to be trusted with tools like "rm",
but who need real shell access to that system anyway. And sometimes
management won't allow users to have two accounts on the same system
(one that is fixed to git-shell, and one that has a real shell)
because the world would implode if a user was given two different
accounts for two different access purposes. I have no idea why that
would happen, but someone paid 3x what I earn has figured that out.
Last I checked how UNIX filesystem access controls work, Git's
core.sharedrepository cannot possibly prevent a user from doing
something like this:
cd $repo_path
git log
... go to lunch ...
rm -rf *
git log
... bitch about how crappy git is ...
Now any "real" version control and SQL database system allows the
administrator to restrict access to the database to avoid such
mistakes. CVS has pserver; SVN can use Apache HTTPd or its own
server; Perforce has its own server. PostgreSQL, Oracle, Informix,
DB2, even MySQL don't allow users to directly read or modify the
database files but instead ask them to go through authenticated
socket based interfaces.
Under a DSCM one would say the central model is insane, and that
every user should have their own repository, with write access
limited to only that user. Obviously this is the model that
kernel.org uses for kernel development, and that git itself uses
for git development.
The problem is the purely distributed model falls apart when you have
50 "Aunt Tillies" making changes to the same 30 files at around the
same time. Its bad enough that they have to have a local clone and
push and fetch to share their changes. Trying to explain that you
need to fetch+merge from Jane right now and Bob 3 minutes later,
then back to Jane to get the changes you are working on in parallel
is sheer chaos. Eyes gloss over and management declares "Git is
crap; it cannot possibly be used in the enterprise".
How do you setup 50 URLs into all 50 user's .git/config? When a new
user joins the project how do you get their URL into all existing
user's trees? Its total chaos in the cube farm as they shout back
and forth "Did you get Bob's changes? Jane's? Oh, maybe you didn't
get Sally's too and that's why you aren't seeing X in there".
At day-job I manage two completely different workflows, but both
are based upon Git.
Real developers who hack out program source code use a model much
like kernel.org. Code is developed on topic branches, code is
reviewed on topic branches at the individual change level, and code
is merged from a developer's topic branch by a maintainer into a
master branch. For convience sake we store all topic branches in a
single central repository, so everyone just has to have the "origin"
URL in their local repositories. We could deal with individual
developer repos like kernel.org does. We choose not to simply
because we also have to handle the next case, and its easier to
not have individual developer repos.
Aunt Tillies (who far out number real developers) edit small text
files through a fancy GUI tool. These folks don't really care
about versions, topic branches, and really don't want to know.
All they know is they have to edit "Foo.data_file" but to do so
they need the changes just made to "Bar.data_file" 5 minutes ago.
Usually they don't even know if Bob, Sally, Jane or Nick made that
change, they just know they need it. And their collective changes
(from all 50 Aunt Tillies) all have to somehow wind up in the same
Git branch at the end of the day so a real developer/maintainer
can pull it into a product build.
I've lived through the daily fires of these workflows over the past
year and a half. Its mostly settled out to something that works very
well for us, but its heavily based upon this concept of a central,
shared repository. And to keep the auditors and management happy
I cannot allow "rm -rf *" to be executed by a user who happens to
have push access to that same repository.
We're not the only Git user that has a shared repository. Doesn't
X.org use a shared repository model? I'm guessing that since they
are an open source project they have less concerns about the "rm
-rf *" case. Wasn't the receive-pack service added to git-daemon
to allow users to push into a repository, but not actually have
write access to its filesystem? Obviously someone else other than
just me wants to safeguard the repository.
--
Shawn.