On Thu, 31 Mar 2016 07:08:01 -0700 (PDT)
Fabio Graciotti <fabio.gracio...@gmail.com> wrote:

> Hello to everyone,
> i'm developing a cloud platform for storing files, in which the users
> can publish a project in order to share it with other users.
> On this platform a group of users work on the same repository, but
> not all of them can access to whole repository, but only some parts
> like subfolders or individual files.
> Is possible develop a git plugin in order to set which users have the 
> access rights on the subfolders and individual files?
> If yes, what programming language i have to use?

It's not easy to answer your question for a number of reasons.

First and foremost you definitely have to absorb the idea that in a
DVCS world per-directory and per-file access controls to a remote
repository is always a hack.  It may work OK but it will eminently work
against the grain of the very idea of a DVCS.

To understand this you should take into account that centralized
systems typically allow you to check out only a single specific "folder"
existing in the specified project's revision and then send some changes
made to its contents back -- producing a synthetic commit on the server.

The crucial difference Git, being a DVCS, maintains in comparison to
this scheme, is that commits in a Git repository always happen in a
local repository (not "on the server"), and each commit refers to the
complete state of the project.  Let me repeat: each commit is a slice
of the project's history and is a snapshot of the whole project.
This explains why it's impossible to fetch (obtain) from a remote
repository only the history of a particular "folder": it simply does
not exist because the history is a linked series of snapshots of the
whole project.

Pretty much due to the same reason (commits always happen locally and
represent the whole project) you can't push (send) only a history
touching a particular "folder" to a remote repository and having it
somehow "integrated" there.

Having explained that, we can move to the gist of the issue with
"fine-grained" access control to a shared Git repository.
By now you should understand that basically what you can do is to
somehow arm Git itself with some tool or create some shim which would
do two things:

* When someone attempts to push their commits to the target repository,
  the tool would figure out what "refs" (branches and tags) these
  commits are about to update, then traverse these chains of commits
  and see if they change any files under prefixes ("folders") the sender
  is not permitted to change.  If so, the push will be rejected,
  completely.

* Access control to fetching can only go as far as restrict access to
  particular "refs" -- because you can't fetch the history of a single
  "folder".

As to a particular implementation, this can be done (and is routinely
done) using the so-called "hooks" which are scripts (or binary programs)
which are "plugged" into a particular Git repository so that they run
by a Git instance "serving" access to that repository at particular
points of the data exchange with the remote Git instance (which attempts
to push or fetch stuff).  Read the githooks manual page for more info.

Git communicates with its hooks via the standard I/O streams and the
exit code:  the hooks must be able to read from their standard input
stream and exit with the zero or non-zero exit code to indicate "can
proceed" or "cannot proceed" condition.  Whatever they write to their
standard error stream is communicated back to the remote Git instance.

To inspect the chain of commits being pushed, the hook should typically
defer to the Git plumbing (low-level) tools such as `git ls-tree` etc.

So a hook can be implemented using most existing programming languages
provided they are able to communicate with the host OS facilities --
standard I/O streams and exit codes -- and spawn and control external
command-line programs (Git plumbing tools).

Now I'd suggest you to just google existing implementations.
You could start with reading the source code of gitolite.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to