Does git have "Path-Based Authorization"?

Hello, I'm trying to decide between git and subversion.  Subversion
has "Path-Based Authorization" so I can give a developer access to
only specific files instead of everything.  Does git have something
similar?

http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html

- Grant

On Fri, 2011-09-30 at 16:43 -0700, Grant wrote:

Hello, I'm trying to decide between git and subversion.  Subversion
has "Path-Based Authorization" so I can give a developer access to
only specific files instead of everything.  Does git have something
similar?

Git's model does not allow the same type "Path-Based Authorization" that
Subversion uses, because git uses secure hash sums to make sure that
people don't try to sneak changes into a pull request or merge, and you
can't selectively download parts of the tree because then you couldn't
check that one of your remotes isn't trying to lie to you.

You can do something that is (or can be) similar with git and
gitolite[0] so a developer (or set of developers) only has access to a
particular set of branches. Depending on what exactly you're trying to
do, this can be more or less complicated to set up. If you only want a
set of developers to access the subdirectory
clients/importantsecretclient, then you create that directory only in
the branch or branches that developer can read. There are many examples
int he gitolite wiki.

[0] https://github.com/sitaramc/gitolite/wiki/

HTH

   cmn

quoted

Hello, I'm trying to decide between git and subversion.  Subversion
has "Path-Based Authorization" so I can give a developer access to
only specific files instead of everything.  Does git have something
similar?

Git's model does not allow the same type "Path-Based Authorization" that
Subversion uses, because git uses secure hash sums to make sure that
people don't try to sneak changes into a pull request or merge, and you
can't selectively download parts of the tree because then you couldn't
check that one of your remotes isn't trying to lie to you.

You can do something that is (or can be) similar with git and
gitolite[0] so a developer (or set of developers) only has access to a
particular set of branches. Depending on what exactly you're trying to
do, this can be more or less complicated to set up. If you only want a
set of developers to access the subdirectory
clients/importantsecretclient, then you create that directory only in
the branch or branches that developer can read. There are many examples
int he gitolite wiki.

I have a series of files containing server-side code which make up a
website.  The entire layout contains only a few folders, but those
folders contain many files.  I want to be able to allow access to only
certain files at a time, sometimes only a single file.  Can that be
done in the way you describe?

- Grant

[0] https://github.com/sitaramc/gitolite/wiki/

HTH

  cmn

On Sat, Oct 1, 2011 at 11:31 AM, Grant [off-list ref] wrote:

I have a series of files containing server-side code which make up a
website.  The entire layout contains only a few folders, but those
folders contain many files.  I want to be able to allow access to only
certain files at a time, sometimes only a single file.  Can that be
done in the way you describe?

If you can gather all sensitive files in a subdirectory, then you can
split that directory into its own repository (see git-submodule man
page) and grant limited access to that repo.
-- 
Duy

quoted

I have a series of files containing server-side code which make up a
website.  The entire layout contains only a few folders, but those
folders contain many files.  I want to be able to allow access to only
certain files at a time, sometimes only a single file.  Can that be
done in the way you describe?

If you can gather all sensitive files in a subdirectory, then you can
split that directory into its own repository (see git-submodule man
page) and grant limited access to that repo.
--
Duy

I thought about separating files the dev has had access to into a
separate folder from files the dev hasn't had access to, but it would
mean constantly changing the code as files move around, plus it would
be too complicated if I have multiple devs and want to give them
access to different stuff.  It's not that some files are more
sensitive than others, it's just that I don't want to give anyone
access to more than I have to.

- Grant

On Fri, 30 Sep 2011, Grant wrote:

quoted

quoted

I have a series of files containing server-side code which make up a
website.  The entire layout contains only a few folders, but those
folders contain many files.  I want to be able to allow access to only
certain files at a time, sometimes only a single file.  Can that be
done in the way you describe?

If you can gather all sensitive files in a subdirectory, then you can
split that directory into its own repository (see git-submodule man
page) and grant limited access to that repo.
--
Duy

I thought about separating files the dev has had access to into a
separate folder from files the dev hasn't had access to, but it would
mean constantly changing the code as files move around, plus it would
be too complicated if I have multiple devs and want to give them
access to different stuff.  It's not that some files are more
sensitive than others, it's just that I don't want to give anyone
access to more than I have to.

the thing to think about is why would you want to give a dev access to a 
file or restrict their access.

Remember that the Dev should be able to test their changes, so you really 
need to give them access to enough stuff to be a complete, working set.

If you make each set of things it's own repository, then you should have 
the granularity you are looking for.

If you think you will need more granularity, please explain what you are 
thinking of?

Also remember that you don't want to have your development files on your 
production site, so you probably don't want to deploy directly from your 
repository to the production site. If you use a filter to make a new git 
repository that only contains the pieces that you are wanting to publish, 
and keep that repository clean, only submitting the files that you want 
there, but treat it as a read-only repository (i.e. no development work 
done there), you should be in good shape.

David Lang

Grant [off-list ref] writes:

Hello, I'm trying to decide between git and subversion.  Subversion
has "Path-Based Authorization" so I can give a developer access to
only specific files instead of everything.  Does git have something
similar?

http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html

 
In distributed version control systems each developers gets full copy
(a clone) of a repository (separate repository instance).  This means that
if you want for developer to see only specified subset of repository
(specific subdirectories) you would have to split repository into
submodules, and control access on (sub)repository basis.


However if you want only to prevent developer from making changes outside
specific subdirectory or specified files, you can do that on publish time
via update / pre-receive hook (like contrib/hooks/update-paranoid), or git
repository management tool such as Gitolite.  That would prevent a push if
any of commits being published touches files that it shouldn't.

P.S. Karl Fogel in "Producing Open Source Software" (http://producingoss.com)
writes that social solutions wrt. restricting contributors to given area
are better than technical solutions such as (overly-)strict access
control.

HTH
-- 
Jakub Narębski

quoted

Hello, I'm trying to decide between git and subversion.  Subversion
has "Path-Based Authorization" so I can give a developer access to
only specific files instead of everything.  Does git have something
similar?

http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html

In distributed version control systems each developers gets full copy
(a clone) of a repository (separate repository instance).  This means that
if you want for developer to see only specified subset of repository
(specific subdirectories) you would have to split repository into
submodules, and control access on (sub)repository basis.

I do want to prevent reading of all but one or a few specified files
at a time.  I did some reading on the differences between centralized
and distributed version control systems, and I can see how a
distributed system may be better for open source projects, but a
business project like mine may work better with centralized control.
Would you guys agree in general?  Easier read/write control of
individual files in the repository is one benefit of the centralized
model I will put to use.

However if you want only to prevent developer from making changes outside
specific subdirectory or specified files, you can do that on publish time
via update / pre-receive hook (like contrib/hooks/update-paranoid), or git
repository management tool such as Gitolite.  That would prevent a push if
any of commits being published touches files that it shouldn't.

P.S. Karl Fogel in "Producing Open Source Software" (http://producingoss.com)
writes that social solutions wrt. restricting contributors to given area
are better than technical solutions such as (overly-)strict access
control.

When I started this thread, I didn't realize the fact that my project
is not open-source would help decide which version control system to
use.  Now I see that it does factor into the decision so I apologize
for not mentioning it previously.

- Grant

On Sun, Oct 2, 2011 at 5:30 AM, Grant [off-list ref] wrote:

quoted

quoted

Hello, I'm trying to decide between git and subversion.  Subversion
has "Path-Based Authorization" so I can give a developer access to
only specific files instead of everything.  Does git have something
similar?

http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html

In distributed version control systems each developers gets full copy
(a clone) of a repository (separate repository instance).  This means that
if you want for developer to see only specified subset of repository
(specific subdirectories) you would have to split repository into
submodules, and control access on (sub)repository basis.

I do want to prevent reading of all but one or a few specified files
at a time.  I did some reading on the differences between centralized
and distributed version control systems, and I can see how a
distributed system may be better for open source projects, but a
business project like mine may work better with centralized control.
Would you guys agree in general?  Easier read/write control of
individual files in the repository is one benefit of the centralized
model I will put to use.

quoted

However if you want only to prevent developer from making changes outside
specific subdirectory or specified files, you can do that on publish time
via update / pre-receive hook (like contrib/hooks/update-paranoid), or git
repository management tool such as Gitolite.  That would prevent a push if
any of commits being published touches files that it shouldn't.

P.S. Karl Fogel in "Producing Open Source Software" (http://producingoss.com)
writes that social solutions wrt. restricting contributors to given area
are better than technical solutions such as (overly-)strict access
control.

When I started this thread, I didn't realize the fact that my project
is not open-source would help decide which version control system to
use.  Now I see that it does factor into the decision so I apologize
for not mentioning it previously.

I'm afraid I did not follow the full thread, but I can assure you we
have several "secret secret" type projects at work, both mine as well
as many others.

There are a few occasions when they need the kind of stuff you seem to
want more regularly, (the only one I can really recall is one of our
largest customers has a custom version of one of our product for
themselves and do not want people working on the generic version to
see those changes in case they propagate to their competitors).  We
just do that by using a different repo entirely, and making sure
changes to common code migrate only one way.

Git has too many advantages over legacy VCSs like SVN for people to
throw it over for something as simple as this.

quoted

quoted

quoted

Hello, I'm trying to decide between git and subversion.  Subversion
has "Path-Based Authorization" so I can give a developer access to
only specific files instead of everything.  Does git have something
similar?

http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html

In distributed version control systems each developers gets full copy
(a clone) of a repository (separate repository instance).  This means that
if you want for developer to see only specified subset of repository
(specific subdirectories) you would have to split repository into
submodules, and control access on (sub)repository basis.

I do want to prevent reading of all but one or a few specified files
at a time.  I did some reading on the differences between centralized
and distributed version control systems, and I can see how a
distributed system may be better for open source projects, but a
business project like mine may work better with centralized control.
Would you guys agree in general?  Easier read/write control of
individual files in the repository is one benefit of the centralized
model I will put to use.

quoted

However if you want only to prevent developer from making changes outside
specific subdirectory or specified files, you can do that on publish time
via update / pre-receive hook (like contrib/hooks/update-paranoid), or git
repository management tool such as Gitolite.  That would prevent a push if
any of commits being published touches files that it shouldn't.

P.S. Karl Fogel in "Producing Open Source Software" (http://producingoss.com)
writes that social solutions wrt. restricting contributors to given area
are better than technical solutions such as (overly-)strict access
control.

When I started this thread, I didn't realize the fact that my project
is not open-source would help decide which version control system to
use.  Now I see that it does factor into the decision so I apologize
for not mentioning it previously.

I'm afraid I did not follow the full thread, but I can assure you we
have several "secret secret" type projects at work, both mine as well
as many others.

There are a few occasions when they need the kind of stuff you seem to
want more regularly, (the only one I can really recall is one of our
largest customers has a custom version of one of our product for
themselves and do not want people working on the generic version to
see those changes in case they propagate to their competitors).  We
just do that by using a different repo entirely, and making sure
changes to common code migrate only one way.

How would something like that work in a case like mine where I have a
series of maybe 100 files and I only want to give my developer
read/write access to one or a few files at a time with no read or
write access to any of the other files?  Wouldn't setting up a
different repo for each set of files be difficult to manage?

- Grant

Git has too many advantages over legacy VCSs like SVN for people to
throw it over for something as simple as this.

On Sun, Oct 2, 2011 at 1:53 PM, Grant [off-list ref] wrote:

How would something like that work in a case like mine where I have a
series of maybe 100 files and I only want to give my developer
read/write access to one or a few files at a time with no read or
write access to any of the other files?  Wouldn't setting up a
different repo for each set of files be difficult to manage?

The write part is easy. Just setup hooks to reject updates on those
files (however, notice the offline nature of git, people may commit
locally and the push later, you may need to check commit time on your
hooks).

The reading part is hard, especially the way you put it ("at a time").
The only way I can think of is to not download those objects and try
to fetch from central repo every time the objects are read,
essentially turn git into a central scm again. Git does not support
this and may never do unless there's an reasonable use case.

So I have to ask, why do you do it this way? Once you give read-access
to a developer, he/she can always save the files somewhere, revoking
read access later on would be useless.
-- 
Duy

quoted

How would something like that work in a case like mine where I have a
series of maybe 100 files and I only want to give my developer
read/write access to one or a few files at a time with no read or
write access to any of the other files?  Wouldn't setting up a
different repo for each set of files be difficult to manage?

The write part is easy. Just setup hooks to reject updates on those
files (however, notice the offline nature of git, people may commit
locally and the push later, you may need to check commit time on your
hooks).

The reading part is hard, especially the way you put it ("at a time").
The only way I can think of is to not download those objects and try
to fetch from central repo every time the objects are read,
essentially turn git into a central scm again. Git does not support
this and may never do unless there's an reasonable use case.

So I have to ask, why do you do it this way? Once you give read-access
to a developer, he/she can always save the files somewhere, revoking
read access later on would be useless.

That's true.  I hope to be able to give different developers access to
different parts of the code.  I really don't know if this will work.
I just don't want my code to be stolen and I'm trying to find some way
to prevent that from happening.

- Grant

On Sat, 01 Oct 2011 20:34:43 +0000, Grant wrote:
...

That's true.  I hope to be able to give different developers access to
different parts of the code.  I really don't know if this will work.

Depending on the implementation it may drive away the good devs...

Anyway, what I think you need (for the reasons detailed in the svn list)
is a setup where the whole project is checked out in the staging area
where it can be tested in whatever way. That under a user id different
from the dev's. Then you change permissions so that he can only see
and edit the files you want him to. This at least eases the problem
of having to commit for each test, and gives you a meaningful history.
Additionally have sudo permissions to do commits etc. in the staging area.

(But still the dev's life will be, erm, suboptimal.)

I just don't want my code to be stolen and I'm trying to find some way
to prevent that from happening.

I'm just getting creative. When the one file that you allow access to
is server-side code (as opposed to, say, css or client js) then the
malevolent dev can use that to read the rest of the staging area anyway.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

On Sun, 02 Oct 2011 05:34:43 +0200, Grant [off-list ref] wrote:

That's true.  I hope to be able to give different developers access to
different parts of the code.  I really don't know if this will work.
I just don't want my code to be stolen and I'm trying to find some way
to prevent that from happening.

To me it seems like you don't trust your developers? If you run a
business and you hire external developers, have them sign an NDA.
Should be legally binding.

I as a developer would be severely insulted if my boss tried to keep
me away from some code, just because he was afraid it might get stolen.

If you don't trust them, fix your trust and relationship, not some tool.

Just my two cents.

Have a good one,
Frans

* Frans Klaver [off-list ref] wrote:

Putting on my business consultant hat:

If you don't trust them, fix your trust and relationship, not some tool.

ACK. We're essentially talking about a social/political problem,
bot a technical one. Take my advise, solve the problem on the
layer it comes from.

The whole ideology of keeping individual devs on their little
tiny isle is to have the whole project structured into such
little islands in the first place. Meaning: a really strong
compartimentalization. This requires an strictly modular
architecture (which essentially means having completely
separate trees for the individual modules) and, of course,
good requirements engineering, contract-driven development,
etc, with all the associated role models, etc, etc.

What kind of project are we talking about ?
Tactical control or nuclear plant systems ?


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------