You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by mi...@euphonynet.be on 2006/09/19 13:54:43 UTC
subversion-authorization (other than authz)
Hello,
I checked on roadmap-site of subversiona nd can't seem to find any plans
to provide a kind of plugin-system to provide additional methods of
authorization . This is a point in which subversion is lacking to my
opinion. I could use apache to direct this, but I don't find this a good
solution. If I would use apache to limit access, those permissions
wouldn't be applied when ssh+svn would be used (which isn't the case).
However, we use trac, which also only shows the content that a user may
view, based on the authz-file. So, using apache for authorization would
allow users to view the content through the trac-browse-feature.
I could synchronize the files manually or using hooks to update the
authz-file, but I'm not sure if that covers everything (have to check) and
a plugin-system of a direct ldap-implentation would be better.
So, are there any plans to implement ldap-authorization and is there a
planning?
Thank you and greetings,
Michel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
[SPAM?] Re: subversion-authorization (other than authz)
Posted by Michel Brabants <mi...@euphonynet.be>.
Hello,
it would also be nice to have an api to change the permissions. These could be added to the classes that implement the retrieving/storing of authorization-data (I mentionned them earlier.). I suppose that there could be a general security-interface to the different (types of) data in a repository (directory, file, property, ...) that also describes what security-settings can be applied to them. This interface should then be implemented by the classes that store the security-settings.
There could be permissions who is allowed to change the permissions ...
I know that this is recursive, which might be handy ... I'll leave it open for a moment.
Greetings,
Michel
Op dinsdag 19 september 2006 23:12, schreef Michel Brabants:
> Hello,
>
> a little, but important correction.
>
> Op dinsdag 19 september 2006 23:07, schreef Michel Brabants:
> > Hello,
> >
> > I'm nto sure if I'll have a look ath the patch because I wouldn't like the
> > maintenance-time it could cost me. Maybe I'll have a look ...
> >
> > Let's see how I would design it ... :)
> >
> > Op dinsdag 19 september 2006 20:51, schreef Lieven Govaerts:
> > > michel.brabants@euphonynet.be wrote:
> > > > Hello,
> > > >
> > > > I checked on roadmap-site of subversiona nd can't seem to find any plans
> > > > to provide a kind of plugin-system to provide additional methods of
> > > > authorization . This is a point in which subversion is lacking to my
> > > > opinion. I could use apache to direct this, but I don't find this a good
> > > > solution. If I would use apache to limit access, those permissions
> > > > wouldn't be applied when ssh+svn would be used (which isn't the case).
> > > > However, we use trac, which also only shows the content that a user may
> > > > view, based on the authz-file. So, using apache for authorization would
> > > > allow users to view the content through the trac-browse-feature.
> > > > I could synchronize the files manually or using hooks to update the
> > > > authz-file, but I'm not sure if that covers everything (have to check) and
> > > > a plugin-system of a direct ldap-implentation would be better.
> > > >
> > > > So, are there any plans to implement ldap-authorization and is there a
> > > > planning?
> > > >
> > > This has been discussed before, but there's no real set of requirements
> > > let alone a design of how that will look like. Feel free to step in :)
> > >
> >
> > Maybe an important note: I'm not so familiar with the code of the
> > subversion-system.
> > Ok, this is a quick try ...
> >
> > * Requirements:
> > It has to define who can access which data in the subversion-system.
> >
> > * Which are the different types of data in the subversion-system, are there
> > dependencies between them and what type of data do they expose?
> >
> > types of data:
> > 1) versionned data -> versionned files, directories and the relationships
> > between them.
> > 2) subversion-properties that are part of a particular version? For example:
> > log-data(?), bug-id, ...
> >
> > I'll leave the dependencies a little bit open for the moment although it at
> > least partly mentionned above.
> >
> > 1)
> > + So, to have full controll, one should have access-control on all data in a
> > change-set. Now, let's say that a file A appears in changesets 1,2 and 5. An
> > entity John has access to the file in changesets 1 and 5, but not in 2.
> > However, the patch for the file A in changeset 2 can be applied properly
> > without the changes in changeset 2.
> The latter sentence should be: However, the patch for the file A in changeset 5 can be applied properly without the changes in changeset 2.
> > What should one do? Maybe another entity
> > Jeffrey was adding information to the file 1 in changeset 2 that shouldn't be
> > disclosed to the entity John, so that is why John doesn has access to the
> > patch for file A in changeset 2. However, this means that the view of how the
> > patch for file 1 should look like after changeset 2 is different for John and
> > Jeffrey. The "worst" part is, that if there would be a conflict because of
> > John uploading a patch after changeset 2, John would have a difficult time
> > resolving the problem because he doesn't have access to the changes.
> > If you would do this in a "secure" way, one would encrypt each separate part
> > according to the persons who have access to the data. Maybe one could write
> > this down in a more formal way ... Maybe it helps. Ofcourse, the data could
> > appear unencrypter afterwards ... So, if one would apply restrictions on
> > already existing changesets ..., one can cause conflicts n the context of the
> > view that those restrictions create on the repository. One should be able to
> > see the conflicts it creates when the restrictions are applied ...
> >
> > + Additional logic could be applied by saying that if a complete file/part(?)
> > is hidden completely from entity John in revision 7, that that file is also
> > hidden from John in revision 2 from then onwards. The file wasn't hidden from
> > the entity John in revision 2. Ofcourse, the entity John could already have
> > downloaded the file as it existed in revision 2.
> >
> > 2) Log-data can apply to parts of code, ... With this I mean, that it could
> > reveal data concerning data that was hidden from the user. I'll stop here for
> > the moment ...
> >
> > Maybe I went already further than what you meant, but I would like to have
> > versionned access-controll. Why? Let's say that I move a file, then the
> > restrictions of the "old" version should still be applied to the new one.
> > However, one can say that I'm already describing behavour that is not wanted
> > by everyone. This is true and I think that it doesn't matter in my above
> > explanation when security is applied to parts within changesets. One could
> > describe their own behaviour when the above explanation is applied (after
> > improvement maybe). Another example maybe. What when I have defined a
> > directory as a way of protecting my files and afterwards I move a file ...
> > This could actually be a wrong way of applying permissions. There should be a
> > permission of not be able to see/delete/... files. A directory is only the
> > groupation(?) of files. However, one could maybe define logic-rules that will
> > allow the method of "a directory protecting files" still to be secure.
> > This seem to be getting a security-implementation. This is actually true I
> > think :).
> >
> > So, to conclude. When a person applies a patch, the repository should call an
> > api that shows restricts it to the context of the user. More specifcally, it
> > shows him the repository as the user would/should see it and then applies the
> > operation of the user. Ofcourse, there could be conflicts with views (of the
> > repository) of other users ...
> > Maybe there already exist theories about security for versionned data ... it
> > is actually not "more" I think than relationships between data which cause
> > the security-data to be applied to other data also.
> >
> > Ok, I know that the authorization-information is not versionned now, but maybe
> > it would be interesting to version it like mentionned above.
> > ----------------------
> > Ofcourse the api ...
> >
> > + getRepositoryView(entity) for getting the view on the repoitory. I don't
> > care if the security-information (what he may see) is available in a
> > text-file, in a database, an ldap-server of in which format it could exist.
> > If groups are also used, the groups that appear in the repository could be
> > fetched from an ldap-server. Ofcourse, there is information-exposure to the
> > ldap-server, but ok I'll leave it at this for now :).
> >
> > getRepositoryView returns a repository-object which allows to browse the
> > repository as the user sees it. The repository-object contains files,
> > directories, properties and all the other (types of) data available in the
> > repository. One could implement the object that returns the view as a
> > different server (like it is maybe now), so that one could easily build a
> > (fuse-)filesystem or so on top of it ...
> >
> > The object that returns the repository could implement a function
> > + getRepositoryView(DataRestrictions/DataAllowonce) (or an object that returns
> > this information)
> > The object that return the information could be a textreader for a specific
> > format, a class that reads the information from a database or an ldap-server.
> > These classes would define what type of information they need to define the
> > datarestrictions/allowances.
> > Explicitly allowing data could maybe usefull for avoiding mistakes ... Why
> > should denying it later overwrite allowing it earlier?
> >
> > I hope that this information was usefull. Greetings,
> >
> > Michel
> >
> > > Some time ago there was a patch on the dev list which might or might not
> > > do what you want:
> > > http://svn.haxx.se/dev/archive-2006-07/0107.shtml
> > >
> > > Lieven.
> > >
> >
> >
> >
>
Re: subversion-authorization (other than authz)
Posted by Michel Brabants <mi...@euphonynet.be>.
Hello,
a little, but important correction.
Op dinsdag 19 september 2006 23:07, schreef Michel Brabants:
> Hello,
>
> I'm nto sure if I'll have a look ath the patch because I wouldn't like the
> maintenance-time it could cost me. Maybe I'll have a look ...
>
> Let's see how I would design it ... :)
>
> Op dinsdag 19 september 2006 20:51, schreef Lieven Govaerts:
> > michel.brabants@euphonynet.be wrote:
> > > Hello,
> > >
> > > I checked on roadmap-site of subversiona nd can't seem to find any plans
> > > to provide a kind of plugin-system to provide additional methods of
> > > authorization . This is a point in which subversion is lacking to my
> > > opinion. I could use apache to direct this, but I don't find this a good
> > > solution. If I would use apache to limit access, those permissions
> > > wouldn't be applied when ssh+svn would be used (which isn't the case).
> > > However, we use trac, which also only shows the content that a user may
> > > view, based on the authz-file. So, using apache for authorization would
> > > allow users to view the content through the trac-browse-feature.
> > > I could synchronize the files manually or using hooks to update the
> > > authz-file, but I'm not sure if that covers everything (have to check) and
> > > a plugin-system of a direct ldap-implentation would be better.
> > >
> > > So, are there any plans to implement ldap-authorization and is there a
> > > planning?
> > >
> > This has been discussed before, but there's no real set of requirements
> > let alone a design of how that will look like. Feel free to step in :)
> >
>
> Maybe an important note: I'm not so familiar with the code of the
> subversion-system.
> Ok, this is a quick try ...
>
> * Requirements:
> It has to define who can access which data in the subversion-system.
>
> * Which are the different types of data in the subversion-system, are there
> dependencies between them and what type of data do they expose?
>
> types of data:
> 1) versionned data -> versionned files, directories and the relationships
> between them.
> 2) subversion-properties that are part of a particular version? For example:
> log-data(?), bug-id, ...
>
> I'll leave the dependencies a little bit open for the moment although it at
> least partly mentionned above.
>
> 1)
> + So, to have full controll, one should have access-control on all data in a
> change-set. Now, let's say that a file A appears in changesets 1,2 and 5. An
> entity John has access to the file in changesets 1 and 5, but not in 2.
> However, the patch for the file A in changeset 2 can be applied properly
> without the changes in changeset 2.
The latter sentence should be: However, the patch for the file A in changeset 5 can be applied properly without the changes in changeset 2.
> What should one do? Maybe another entity
> Jeffrey was adding information to the file 1 in changeset 2 that shouldn't be
> disclosed to the entity John, so that is why John doesn has access to the
> patch for file A in changeset 2. However, this means that the view of how the
> patch for file 1 should look like after changeset 2 is different for John and
> Jeffrey. The "worst" part is, that if there would be a conflict because of
> John uploading a patch after changeset 2, John would have a difficult time
> resolving the problem because he doesn't have access to the changes.
> If you would do this in a "secure" way, one would encrypt each separate part
> according to the persons who have access to the data. Maybe one could write
> this down in a more formal way ... Maybe it helps. Ofcourse, the data could
> appear unencrypter afterwards ... So, if one would apply restrictions on
> already existing changesets ..., one can cause conflicts n the context of the
> view that those restrictions create on the repository. One should be able to
> see the conflicts it creates when the restrictions are applied ...
>
> + Additional logic could be applied by saying that if a complete file/part(?)
> is hidden completely from entity John in revision 7, that that file is also
> hidden from John in revision 2 from then onwards. The file wasn't hidden from
> the entity John in revision 2. Ofcourse, the entity John could already have
> downloaded the file as it existed in revision 2.
>
> 2) Log-data can apply to parts of code, ... With this I mean, that it could
> reveal data concerning data that was hidden from the user. I'll stop here for
> the moment ...
>
> Maybe I went already further than what you meant, but I would like to have
> versionned access-controll. Why? Let's say that I move a file, then the
> restrictions of the "old" version should still be applied to the new one.
> However, one can say that I'm already describing behavour that is not wanted
> by everyone. This is true and I think that it doesn't matter in my above
> explanation when security is applied to parts within changesets. One could
> describe their own behaviour when the above explanation is applied (after
> improvement maybe). Another example maybe. What when I have defined a
> directory as a way of protecting my files and afterwards I move a file ...
> This could actually be a wrong way of applying permissions. There should be a
> permission of not be able to see/delete/... files. A directory is only the
> groupation(?) of files. However, one could maybe define logic-rules that will
> allow the method of "a directory protecting files" still to be secure.
> This seem to be getting a security-implementation. This is actually true I
> think :).
>
> So, to conclude. When a person applies a patch, the repository should call an
> api that shows restricts it to the context of the user. More specifcally, it
> shows him the repository as the user would/should see it and then applies the
> operation of the user. Ofcourse, there could be conflicts with views (of the
> repository) of other users ...
> Maybe there already exist theories about security for versionned data ... it
> is actually not "more" I think than relationships between data which cause
> the security-data to be applied to other data also.
>
> Ok, I know that the authorization-information is not versionned now, but maybe
> it would be interesting to version it like mentionned above.
> ----------------------
> Ofcourse the api ...
>
> + getRepositoryView(entity) for getting the view on the repoitory. I don't
> care if the security-information (what he may see) is available in a
> text-file, in a database, an ldap-server of in which format it could exist.
> If groups are also used, the groups that appear in the repository could be
> fetched from an ldap-server. Ofcourse, there is information-exposure to the
> ldap-server, but ok I'll leave it at this for now :).
>
> getRepositoryView returns a repository-object which allows to browse the
> repository as the user sees it. The repository-object contains files,
> directories, properties and all the other (types of) data available in the
> repository. One could implement the object that returns the view as a
> different server (like it is maybe now), so that one could easily build a
> (fuse-)filesystem or so on top of it ...
>
> The object that returns the repository could implement a function
> + getRepositoryView(DataRestrictions/DataAllowonce) (or an object that returns
> this information)
> The object that return the information could be a textreader for a specific
> format, a class that reads the information from a database or an ldap-server.
> These classes would define what type of information they need to define the
> datarestrictions/allowances.
> Explicitly allowing data could maybe usefull for avoiding mistakes ... Why
> should denying it later overwrite allowing it earlier?
>
> I hope that this information was usefull. Greetings,
>
> Michel
>
> > Some time ago there was a patch on the dev list which might or might not
> > do what you want:
> > http://svn.haxx.se/dev/archive-2006-07/0107.shtml
> >
> > Lieven.
> >
>
>
>
Re: subversion-authorization (other than authz)
Posted by Michel Brabants <mi...@euphonynet.be>.
Hello,
I'm nto sure if I'll have a look ath the patch because I wouldn't like the
maintenance-time it could cost me. Maybe I'll have a look ...
Let's see how I would design it ... :)
Op dinsdag 19 september 2006 20:51, schreef Lieven Govaerts:
> michel.brabants@euphonynet.be wrote:
> > Hello,
> >
> > I checked on roadmap-site of subversiona nd can't seem to find any plans
> > to provide a kind of plugin-system to provide additional methods of
> > authorization . This is a point in which subversion is lacking to my
> > opinion. I could use apache to direct this, but I don't find this a good
> > solution. If I would use apache to limit access, those permissions
> > wouldn't be applied when ssh+svn would be used (which isn't the case).
> > However, we use trac, which also only shows the content that a user may
> > view, based on the authz-file. So, using apache for authorization would
> > allow users to view the content through the trac-browse-feature.
> > I could synchronize the files manually or using hooks to update the
> > authz-file, but I'm not sure if that covers everything (have to check) and
> > a plugin-system of a direct ldap-implentation would be better.
> >
> > So, are there any plans to implement ldap-authorization and is there a
> > planning?
> >
> This has been discussed before, but there's no real set of requirements
> let alone a design of how that will look like. Feel free to step in :)
>
Maybe an important note: I'm not so familiar with the code of the
subversion-system.
Ok, this is a quick try ...
* Requirements:
It has to define who can access which data in the subversion-system.
* Which are the different types of data in the subversion-system, are there
dependencies between them and what type of data do they expose?
types of data:
1) versionned data -> versionned files, directories and the relationships
between them.
2) subversion-properties that are part of a particular version? For example:
log-data(?), bug-id, ...
I'll leave the dependencies a little bit open for the moment although it at
least partly mentionned above.
1)
+ So, to have full controll, one should have access-control on all data in a
change-set. Now, let's say that a file A appears in changesets 1,2 and 5. An
entity John has access to the file in changesets 1 and 5, but not in 2.
However, the patch for the file A in changeset 2 can be applied properly
without the changes in changeset 2. What should one do? Maybe another entity
Jeffrey was adding information to the file 1 in changeset 2 that shouldn't be
disclosed to the entity John, so that is why John doesn has access to the
patch for file A in changeset 2. However, this means that the view of how the
patch for file 1 should look like after changeset 2 is different for John and
Jeffrey. The "worst" part is, that if there would be a conflict because of
John uploading a patch after changeset 2, John would have a difficult time
resolving the problem because he doesn't have access to the changes.
If you would do this in a "secure" way, one would encrypt each separate part
according to the persons who have access to the data. Maybe one could write
this down in a more formal way ... Maybe it helps. Ofcourse, the data could
appear unencrypter afterwards ... So, if one would apply restrictions on
already existing changesets ..., one can cause conflicts n the context of the
view that those restrictions create on the repository. One should be able to
see the conflicts it creates when the restrictions are applied ...
+ Additional logic could be applied by saying that if a complete file/part(?)
is hidden completely from entity John in revision 7, that that file is also
hidden from John in revision 2 from then onwards. The file wasn't hidden from
the entity John in revision 2. Ofcourse, the entity John could already have
downloaded the file as it existed in revision 2.
2) Log-data can apply to parts of code, ... With this I mean, that it could
reveal data concerning data that was hidden from the user. I'll stop here for
the moment ...
Maybe I went already further than what you meant, but I would like to have
versionned access-controll. Why? Let's say that I move a file, then the
restrictions of the "old" version should still be applied to the new one.
However, one can say that I'm already describing behavour that is not wanted
by everyone. This is true and I think that it doesn't matter in my above
explanation when security is applied to parts within changesets. One could
describe their own behaviour when the above explanation is applied (after
improvement maybe). Another example maybe. What when I have defined a
directory as a way of protecting my files and afterwards I move a file ...
This could actually be a wrong way of applying permissions. There should be a
permission of not be able to see/delete/... files. A directory is only the
groupation(?) of files. However, one could maybe define logic-rules that will
allow the method of "a directory protecting files" still to be secure.
This seem to be getting a security-implementation. This is actually true I
think :).
So, to conclude. When a person applies a patch, the repository should call an
api that shows restricts it to the context of the user. More specifcally, it
shows him the repository as the user would/should see it and then applies the
operation of the user. Ofcourse, there could be conflicts with views (of the
repository) of other users ...
Maybe there already exist theories about security for versionned data ... it
is actually not "more" I think than relationships between data which cause
the security-data to be applied to other data also.
Ok, I know that the authorization-information is not versionned now, but maybe
it would be interesting to version it like mentionned above.
----------------------
Ofcourse the api ...
+ getRepositoryView(entity) for getting the view on the repoitory. I don't
care if the security-information (what he may see) is available in a
text-file, in a database, an ldap-server of in which format it could exist.
If groups are also used, the groups that appear in the repository could be
fetched from an ldap-server. Ofcourse, there is information-exposure to the
ldap-server, but ok I'll leave it at this for now :).
getRepositoryView returns a repository-object which allows to browse the
repository as the user sees it. The repository-object contains files,
directories, properties and all the other (types of) data available in the
repository. One could implement the object that returns the view as a
different server (like it is maybe now), so that one could easily build a
(fuse-)filesystem or so on top of it ...
The object that returns the repository could implement a function
+ getRepositoryView(DataRestrictions/DataAllowonce) (or an object that returns
this information)
The object that return the information could be a textreader for a specific
format, a class that reads the information from a database or an ldap-server.
These classes would define what type of information they need to define the
datarestrictions/allowances.
Explicitly allowing data could maybe usefull for avoiding mistakes ... Why
should denying it later overwrite allowing it earlier?
I hope that this information was usefull. Greetings,
Michel
> Some time ago there was a patch on the dev list which might or might not
> do what you want:
> http://svn.haxx.se/dev/archive-2006-07/0107.shtml
>
> Lieven.
>
Re: subversion-authorization (other than authz)
Posted by Michel Brabants <mi...@euphonynet.be>.
Hello,
it seems to be a solution for the moment, although I'm not sure what to exactly think of it. Although it may be good (for the short run), I'm not so keen of it at the moment.
Thank you and greetings,
Michel
Op dinsdag 19 september 2006 21:05, schreef Mark:
> I'm using ldap auth at my site. We do svn+ssh and http[s] access to
> svn. To cover svn+ssh, we use pam_ldap and mod_ldap/mod_auth_ldap
> with apache. Works fine. For authz, I have a script that runs hourly
> to catch updates in groups (we base the authz on groups from our
> internal sourceforge site) and puts them into the project config/authz
> files as well as the apache (mod_authz_svn) authz file.
>
> Getting svn to work fine with svn+ssh and http(dav) access is not too
> difficult. Plus, if you are using ldap auth for your server anyway,
> there's nothing more to do really.
>
> Now, putting svn authz into ldap would be cool....
>
> On 9/19/06, Lieven Govaerts <sv...@mobsol.be> wrote:
> > michel.brabants@euphonynet.be wrote:
> > > Hello,
> > >
> > > I checked on roadmap-site of subversiona nd can't seem to find any plans
> > > to provide a kind of plugin-system to provide additional methods of
> > > authorization . This is a point in which subversion is lacking to my
> > > opinion. I could use apache to direct this, but I don't find this a good
> > > solution. If I would use apache to limit access, those permissions
> > > wouldn't be applied when ssh+svn would be used (which isn't the case).
> > > However, we use trac, which also only shows the content that a user may
> > > view, based on the authz-file. So, using apache for authorization would
> > > allow users to view the content through the trac-browse-feature.
> > > I could synchronize the files manually or using hooks to update the
> > > authz-file, but I'm not sure if that covers everything (have to check) and
> > > a plugin-system of a direct ldap-implentation would be better.
> > >
> > > So, are there any plans to implement ldap-authorization and is there a
> > > planning?
> > >
> > This has been discussed before, but there's no real set of requirements
> > let alone a design of how that will look like. Feel free to step in :)
> >
> > Some time ago there was a patch on the dev list which might or might not
> > do what you want:
> > http://svn.haxx.se/dev/archive-2006-07/0107.shtml
> >
> > Lieven.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
>
Re: subversion-authorization (other than authz)
Posted by Mark <ma...@mitsein.net>.
I'm using ldap auth at my site. We do svn+ssh and http[s] access to
svn. To cover svn+ssh, we use pam_ldap and mod_ldap/mod_auth_ldap
with apache. Works fine. For authz, I have a script that runs hourly
to catch updates in groups (we base the authz on groups from our
internal sourceforge site) and puts them into the project config/authz
files as well as the apache (mod_authz_svn) authz file.
Getting svn to work fine with svn+ssh and http(dav) access is not too
difficult. Plus, if you are using ldap auth for your server anyway,
there's nothing more to do really.
Now, putting svn authz into ldap would be cool....
On 9/19/06, Lieven Govaerts <sv...@mobsol.be> wrote:
> michel.brabants@euphonynet.be wrote:
> > Hello,
> >
> > I checked on roadmap-site of subversiona nd can't seem to find any plans
> > to provide a kind of plugin-system to provide additional methods of
> > authorization . This is a point in which subversion is lacking to my
> > opinion. I could use apache to direct this, but I don't find this a good
> > solution. If I would use apache to limit access, those permissions
> > wouldn't be applied when ssh+svn would be used (which isn't the case).
> > However, we use trac, which also only shows the content that a user may
> > view, based on the authz-file. So, using apache for authorization would
> > allow users to view the content through the trac-browse-feature.
> > I could synchronize the files manually or using hooks to update the
> > authz-file, but I'm not sure if that covers everything (have to check) and
> > a plugin-system of a direct ldap-implentation would be better.
> >
> > So, are there any plans to implement ldap-authorization and is there a
> > planning?
> >
> This has been discussed before, but there's no real set of requirements
> let alone a design of how that will look like. Feel free to step in :)
>
> Some time ago there was a patch on the dev list which might or might not
> do what you want:
> http://svn.haxx.se/dev/archive-2006-07/0107.shtml
>
> Lieven.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Mark
"Blessed is he who finds happiness in his own foolishness, for he will
always be happy."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: subversion-authorization (other than authz)
Posted by Lieven Govaerts <sv...@mobsol.be>.
michel.brabants@euphonynet.be wrote:
> Hello,
>
> I checked on roadmap-site of subversiona nd can't seem to find any plans
> to provide a kind of plugin-system to provide additional methods of
> authorization . This is a point in which subversion is lacking to my
> opinion. I could use apache to direct this, but I don't find this a good
> solution. If I would use apache to limit access, those permissions
> wouldn't be applied when ssh+svn would be used (which isn't the case).
> However, we use trac, which also only shows the content that a user may
> view, based on the authz-file. So, using apache for authorization would
> allow users to view the content through the trac-browse-feature.
> I could synchronize the files manually or using hooks to update the
> authz-file, but I'm not sure if that covers everything (have to check) and
> a plugin-system of a direct ldap-implentation would be better.
>
> So, are there any plans to implement ldap-authorization and is there a
> planning?
>
This has been discussed before, but there's no real set of requirements
let alone a design of how that will look like. Feel free to step in :)
Some time ago there was a patch on the dev list which might or might not
do what you want:
http://svn.haxx.se/dev/archive-2006-07/0107.shtml
Lieven.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org