Access controls...

[Maritza Mendez]

Catching up on email between flights...

Bzr is billed as "adaptive" and my experience using bzr in a
commercial environment required me to adapt to bzr a little more than
I hoped.

Like it or not access control is a big deal in the enterprise.  There
are modules related to product licensing or "secret sause" that
executives demand restricted access.  Sometimes they are silly.  But
they write the paychecks.  This poses a challenge for any system which
does not use a server protocol and most dvcs in general.  My solution
has been to design repos around security requirements and then set up
ntfs permissions accordingly.  This wastes some disk but it works and
I can tell my boss that the secret stuff is locked up safe.

Anything which makes flexible access controls easy to set up *and*
easy to verify will facilitate enterprise adoption of bzr.

~M


On 5/2/10, John Arbash Meinel <john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John Szakmeister wrote:
>> On Sun, May 2, 2010 at 1:13 PM, Parth Malwankar
>> <parth.malwankar at gmail.com> wrote:
>> [snip]
>>> Hi John,
>>>
>>> I haven't tried it personally but there is some documentation on
>>> setting up fine grained access here.
>>> http://doc.bazaar.canonical.com/bzr.2.1/en/admin-guide/security.html#access-control
>>>
>>> Is that something that might be useful?
>>
>> Not the way it currently stands.  If you look at:
>>
>> <http://doc.bazaar.canonical.com/bzr.2.1/en/admin-guide/security.html#additional-considerations-with-bzr-access>
>>
>> It only allows very limited access controls.  You have assign a key
>> for each repo, and it really doesn't scale well to 40 people and 60+
>> projects.  I did try it though.  I'm more keen on getting things
>> working through http:// style access, if at all possible.
>>
>> Thanks though!
>>
>> -John
>>
>
> I don't remember the project right now, but there was someone who did
> most of the ACLTransport work. It shouldn't be particularly hard to
> implement yourself if we can't find it.
>
> In general, I would leave the repository open for writing to anyone who
> has access to write to a branch in that repo. I don't really know how
> you could be more fine-grained there.
>
> However, that shouldn't make it harder for you to prevent them from
> updating the 'trunk' branch. Yes, they can push data to the shared repo,
> but it goes 'unused' unless it is referenced by a branch. So I'm not
> sure why you need to proxy through the Branch.
>
> John
> =:->
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkvdw6oACgkQJdeBCYSNAAOMAQCeMcsB78T/LzlkFofsaQBijZgn
> E9wAnAlUX75tQmOgah3yfKXujF2hrf/T
> =pQVc
> -----END PGP SIGNATURE-----
>
>