You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Pete Gonzalez <pg...@bluel.com> on 2004/07/24 00:36:04 UTC
Hook scripts -- no support for permissions?
I would like to prevent certain users from accessing certain
directories in my repository. (Note: we are using "svnserve"
instead of the WebDAV quagmire.) I realize that full ACL
permissions are way off the radar, as Subversion is still
in its infancy. (*) However, I noticed a hook script called
"start-commit" that can be used to implement poor man's
ACL permissions for commits.
I am wondering, how difficult would it be to implement something
similar for *viewing* files in the repository? I.e. is there
any reason we couldn't have a "access-directory" hook script for
other operations such as checkout, view log, etc.? I am a
programmer; I would be willing to code this if someone points me
in the right direction for where to start.
Cheers,
-Pete
___
(*) In particular, I am not asking for ACL permissions to be
added as a feature until the following more critical design
holes have been addressed:
- Non-vaporware support for accessing revisions of a
moved/renamed file :-)
- Ability to store binary data files in the repository without
revision histories ("Store only latest version" from SourceSafe)
- Ability to fold old revisions into a single changeset
("cvs admin -o" from CVS)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Hook scripts -- no support for permissions?
Posted by Evan Easton <ev...@eeaston.com>.
I'm with Pete that we need some sort of a minimal as (simple-as-possible)
hook that allows site owners to get more control without having to force
all users to use HTTP access. In my particular case, I've been
experimenting with trac. Trac uses the Python bindings and according to
this Ticket's comments (http://projects.edgewall.com/trac/ticket/493)
doesn't have use the RA layer in order to access the repository through
http URLs.
I certainly don't know enough about svn's innards to determine if their
argument holds water. But I do know that if I could control access to the
repository at the hook level I wouldn't have to worry about whether 3rd
party tools are using the RA layer or acting as simple svn client wrappers
or not.
Maybe you (Ben) can start a thread pointing to some of the issues or
pointing to past discussions so that I could learn enough to contribute to
the discussions???
Evan
> On Fri, 2004-07-23 at 19:36, Pete Gonzalez wrote:
>> I would like to prevent certain users from accessing certain
>> directories in my repository. (Note: we are using "svnserve"
>> instead of the WebDAV quagmire.) I realize that full ACL
>> permissions are way off the radar, as Subversion is still
>> in its infancy. (*) However, I noticed a hook script called
>> "start-commit" that can be used to implement poor man's
>> ACL permissions for commits.
>
> We already have mod_authz_svn for controlling read/write access on
individual directories. As long you're using apache as your server,
you're set to go. (And someday svnserve will probably grow the same
feature.)
>
> If you're using svnserve, as you say, there's no way to get fine-grained
read access right now.
>
>> I am wondering, how difficult would it be to implement something
similar for *viewing* files in the repository?
>
> Read-hooks are hard to do, which is why we haven't implemented them yet.
There are *many* read functions in the repository filesystem API
(svn_fs.h). To implement read hooks, we'd have to "wrap" every one of
these functions with libsvn_repos functions, and then have every program
in the world use svn_repos.h instead of svn_fs.h for reading data.
Messy.
>
> It was much easier to implement write hooks: libsvn_repos only had to
wrap two functions: svn_fs_create_txn() and svn_fs_commit_txn(). And
it's an easy burden on programs accessing the repository to use the 2
libsvn_repos wrappers.
>
> We've even had talks about writing persistent daemons to speed up the
fictional 'read' checks, lest things get too slow. The conversation
gets messy. If you really want to talk about the design, come over to
the dev@ list. ;-)
>
>
>
> --------------------------------------------------------------------- To
unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Hook scripts -- no support for permissions?
Posted by Branko Čibej <br...@xbc.nu>.
Pete Gonzalez wrote:
> At 09:06 PM 7/28/2004, you wrote:
>
>> (A) uses the WebDAV and DeltaV extensions to the HTTP protocol. This
>> protocol is stateless, and the extensions are such that every path
>> that the client wishes to read or modify is noted explicitly in HTTP
>> request headers, which mod_authz_svn can check with (almost) no
>> knowledge of how Subversion actually does its thing.
>>
>> (B) uses a proprietary, stateful protocol that basically does nothing
>> more than marshal Subversion's repository-access API calls (_not_
>> libsvn_repos or libsvn_fs) through a socket connection. Now it would
>> be possible to do the semantic interpretation necessary for access
>> control in the unmarshaler in svnserve, but that would a) duplicate
>> some of the work that other libraries already do, and b) require
>> effort comparable to implementing access control in the repository or
>> FS layer, as I said before.
>
>
> It sounds like what we need is an authentication API interface. In an
> ACL-type environment, any operation can fail unexpectedly because of
> insufficient permissions. The problem seems to be that nobody was
> thinking about this when they wrote the current code base, so we're
> talking about going through all the files and wrapping every single
> operation to add permission checks.
No, not at all. Any operation can _already_ fail because of insufficient
permissions (witness that mod_authz_svn works). There's no need for any
wrapping, and you definitely do not want to check for permissions up front.
> This problem is quite independent of the particular authentication
> rules, be they hook scripts, or mod_authz_svn, or property lists, or
> whatever.
You're confusing authentication with authorization. Hook scripts,
mod_authz_svn, etc. implement authorization -- access contril, if you
will. Authentication is a different can of worms which the SVN
repository and filesystem intentionally ignore.
> In a way, hook scripts are a kind of poor man's API, which is why I
> asked about it originally. But maybe sweeping all the authentication
> logic behind an API would make the integration problem less daunting.
s/authorization/authentication/ and I agree, of course.
> On the other hand, it seems like the real message I'm hearing is
> "Dude, just use WebDAV, nobody uses svnserve." :-)
Bah. I'd estimate about 50% of our users live on svnserve.
>> Buffer overflows? Where?
>
>
> Sorry, apparently the humor didn't survive the e-mail medium. :-)
Well, you scared me because buffer overflows in a server are a serious
matter.
>> This doesn't actually happen quite like that in Subversion, because
>> the actual scenario is
>>
>> svn --> ssh --> svnserve --> Repository --> FileSystem
>>
>> That is, you use ssh for tunneling svnserve's socket connection, not
>> for login onto the server. In fact, CVS does things like that, too.
>>
>> Of course, if you do allow users to log onto the server, whether via
>> SSH or some other mechanism, neither SVN or CVS can do anything to
>> protect your data.
>
>
> Um, a couple remarks on this subject: First, it's ridiculous to
> create a situation where installing a piece of software requires
> revoking everyone's shell access. Regardless of particular Unix
> scenarios, from a design perspective you simply cannot make that kind
> of assumption. Secondly, svnserve does offer data protection -- what
> you do is create a user called "svn" and run svnserve from that user's
> account, so the Unix file permissions prevent any form of access to
> the repository except through svnserve. It's not ACL, but it does
> prevent the grumpy intern from deleting the repository on his way out
> the door.
That's true. What I meant was that, once someone has shell access to the
machine, it's much, much easier for them to somehow grab root access if
they're really determined to do that. Or rather, how much you trust your
users has nothing to do with Subversion. :-)
>> My point is that if we do _not_ implement access control there, we'll
>> be duplicating work in svnserve that we intend to do in Repos/FS in
>> any case.
>
>
> Where does this fall in the Subversion roadmap? And, where is that
> roadmap? I'm having a lot of trouble understanding where everything
> is heading.
I'll let others comment about roadmaps, but we are currently discussing
ACLs and locking for inclusion in one of the upcoming releases
(certainly in the 1.x series). That discussion got sidetracked a bit
because of the 1.1 release effort, and because I'm chronically short on
time (I've been promising the ACL design doc for ages... :-( )
> Thanks again for your comments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Hook scripts -- no support for permissions?
Posted by kf...@collab.net.
Pete Gonzalez <pg...@bluel.com> writes:
> Where does this fall in the Subversion roadmap? And, where is that
> roadmap? I'm having a lot of trouble understanding where everything
> is heading.
The roadmap, such as it is, it is in the issue tracker. Sort open
issues by target-milestone, and you'll get an overview.
Note that because the project runs on volunteer labor, our long-term
plans are pretty flexible. Concrete roadmaps usually only look one or
two releases into the future (six months to a year, in clock time).
We can get pretty hand-wavy about what 2.0 will look like, although we
do have *some* specific plans for it of course.
This attitude is the result of experience. We used to lay out very
detailed long-term strategies, with particular features in particular
milestones, but then some developers would drift off, and new people
with different ideas would join the project, and goals that had looked
realistic six months ago would suddenly seem very tenuous.
So, if you're trying to figure out where things are headed, then
you're in the right mindset :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Hook scripts -- no support for permissions?
Posted by Pete Gonzalez <pg...@bluel.com>.
At 09:06 PM 7/28/2004, you wrote:
>(A) uses the WebDAV and DeltaV extensions to the HTTP protocol. This
>protocol is stateless, and the extensions are such that every path that
>the client wishes to read or modify is noted explicitly in HTTP request
>headers, which mod_authz_svn can check with (almost) no knowledge of how
>Subversion actually does its thing.
>
>(B) uses a proprietary, stateful protocol that basically does nothing more
>than marshal Subversion's repository-access API calls (_not_ libsvn_repos
>or libsvn_fs) through a socket connection. Now it would be possible to do
>the semantic interpretation necessary for access control in the
>unmarshaler in svnserve, but that would a) duplicate some of the work that
>other libraries already do, and b) require effort comparable to
>implementing access control in the repository or FS layer, as I said before.
It sounds like what we need is an authentication API interface. In an
ACL-type environment, any operation can fail unexpectedly because of
insufficient permissions. The problem seems to be that nobody was thinking
about this when they wrote the current code base, so we're talking about
going through all the files and wrapping every single operation to add
permission checks.
This problem is quite independent of the particular authentication rules,
be they hook scripts, or mod_authz_svn, or property lists, or whatever. In
a way, hook scripts are a kind of poor man's API, which is why I asked
about it originally. But maybe sweeping all the authentication logic
behind an API would make the integration problem less daunting.
On the other hand, it seems like the real message I'm hearing is "Dude,
just use WebDAV, nobody uses svnserve." :-)
>Buffer overflows? Where?
Sorry, apparently the humor didn't survive the e-mail medium. :-)
>This doesn't actually happen quite like that in Subversion, because the
>actual scenario is
>
> svn --> ssh --> svnserve --> Repository --> FileSystem
>
>That is, you use ssh for tunneling svnserve's socket connection, not for
>login onto the server. In fact, CVS does things like that, too.
>
>Of course, if you do allow users to log onto the server, whether via SSH
>or some other mechanism, neither SVN or CVS can do anything to protect
>your data.
Um, a couple remarks on this subject: First, it's ridiculous to create a
situation where installing a piece of software requires revoking everyone's
shell access. Regardless of particular Unix scenarios, from a design
perspective you simply cannot make that kind of assumption. Secondly,
svnserve does offer data protection -- what you do is create a user called
"svn" and run svnserve from that user's account, so the Unix file
permissions prevent any form of access to the repository except through
svnserve. It's not ACL, but it does prevent the grumpy intern from
deleting the repository on his way out the door.
>My point is that if we do _not_ implement access control there, we'll be
>duplicating work in svnserve that we intend to do in Repos/FS in any case.
Where does this fall in the Subversion roadmap? And, where is that
roadmap? I'm having a lot of trouble understanding where everything is
heading.
Thanks again for your comments.
Cheers,
-Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Hook scripts -- no support for permissions?
Posted by Branko Čibej <br...@xbc.nu>.
Ed MacDonald wrote:
>>This doesn't actually happen quite like that in Subversion, because the
>>actual scenario is
>>
>> svn --> ssh --> svnserve --> Repository --> FileSystem
>>
>>That is, you use ssh for tunneling svnserve's socket connection, not for
>>login onto the server. In fact, CVS does things like that, too.
>>
>>Of course, if you do allow users to log onto the server, whether via SSH
>>or some other mechanism, neither SVN or CVS can do anything to protect
>>your data.
>>
>>
>
>I don't believe that svnserve uses sockets at all in this scenario - just
>stdin/stdout. In which case it is pretty much as Pete so colourfully said,
>you can have your way with the DB since the svnserve process is running as
>the user and must be given read/write on the repo.
>
>
You can restrict the SSH session to only allow the user to execute
svnserve, and you can make svnserve setuid (not to root, of course). The
user can still get to the repository by cracking svnserve, but that's no
different than in scenarion (B).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Hook scripts -- no support for permissions?
Posted by Ed MacDonald <ed...@hotmail.com>.
> This doesn't actually happen quite like that in Subversion, because the
> actual scenario is
>
> svn --> ssh --> svnserve --> Repository --> FileSystem
>
> That is, you use ssh for tunneling svnserve's socket connection, not for
> login onto the server. In fact, CVS does things like that, too.
>
> Of course, if you do allow users to log onto the server, whether via SSH
> or some other mechanism, neither SVN or CVS can do anything to protect
> your data.
I don't believe that svnserve uses sockets at all in this scenario - just
stdin/stdout. In which case it is pretty much as Pete so colourfully said,
you can have your way with the DB since the svnserve process is running as
the user and must be given read/write on the repo.
Actually tunneling the socket is the method I use. It's a two step process
and one not talked about in the book or the FAQ. First you create an ssh
tunnel to the svn server, then you access the repo via "localhost". It has
the advantage that your svn users don't need to have perms on the DB repo
files. And for the really paranoid, you can restrict the svnserve process
to only accept connections from localhost, thus the only exposure needed is
ssh.
I hope I'm right, 'cause that's the way I'm running it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Hook scripts -- no support for permissions?
Posted by Branko Čibej <br...@xbc.nu>.
Pete Gonzalez wrote:
> At 06:00 PM 7/28/2004, you wrote:
>
>>> my proposal: Instead of worrying about hook scripts, why don't we just
>>> expand svnserve's authentication model? In other words, we can
>>> implement
>>> for svnserve a small subset of what WebDAV is doing. This should be an
>>> inexpensive way to extend the old model until a proper ACL mechanism
>>> is designed. I mean shit, svnserve could probably do this using
>>> properties. So... how much work would this be? :-)
>>
>>
>> I have no idea how much work it would be to do that, but I suspect it
>> would touch a significant part of our FS library -- effectively
>> duplicating exactly the same amount of work (and intrusiveness) as
>> needed for read hooks -- or real ACLs, for that matter.
>
>
> No no, I mean these checks would be implemented in serve.c (or
> thereabouts),
> as opposed to integrating them directly into the repository/filesystem
> libraries. Maybe I'm being overly simplistic here,
Yup :-)
> but this is the picture
> in my head (granted I haven't looked very closely at the code):
>
> A. svn --> Apache --> Repository --> FileSystem
>
> B. svn --> svnserve --> Repository --> FileSystem
These two scenarios aren't even remotely comparable as far as access
control is concerned.
(A) uses the WebDAV and DeltaV extensions to the HTTP protocol. This
protocol is stateless, and the extensions are such that every path that
the client wishes to read or modify is noted explicitly in HTTP request
headers, which mod_authz_svn can check with (almost) no knowledge of how
Subversion actually does its thing.
(B) uses a proprietary, stateful protocol that basically does nothing
more than marshal Subversion's repository-access API calls (_not_
libsvn_repos or libsvn_fs) through a socket connection. Now it would be
possible to do the semantic interpretation necessary for access control
in the unmarshaler in svnserve, but that would a) duplicate some of the
work that other libraries already do, and b) require effort comparable
to implementing access control in the repository or FS layer, as I said
before.
> C. svn --> Repository --> FileSystem
>
> Inside the "Apache" box is a fairly elaborate security model. Inside
> the "svnserve" box is a little text file containing some plaintext
> passwords and a few buffer overflows for good measure.
Buffer overflows? Where?
> (Scenario C
> is the fabled "SSH authentication" case from CVS, where you pass
> a triple security check and retinal scan to end up in a dimly lit
> prison cell, wherein you can bend the Berkley database over a table
> and do whatever you like, but everyone knows it was you.)
This doesn't actually happen quite like that in Subversion, because the
actual scenario is
svn --> ssh --> svnserve --> Repository --> FileSystem
That is, you use ssh for tunneling svnserve's socket connection, not for
login onto the server. In fact, CVS does things like that, too.
Of course, if you do allow users to log onto the server, whether via SSH
or some other mechanism, neither SVN or CVS can do anything to protect
your data.
> So my question is: If we just want to add a few more security tests
> inside the "svnserve" box, why would this involve the Repository or
> FileSystem boxes?
My point is that if we do _not_ implement access control there, we'll be
duplicating work in svnserve that we intend to do in Repos/FS in any
case. So it's better to do this once in the right place, than to start
with a hack that won't save much time in the short term and will double
the effort in the long term.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Hook scripts -- no support for permissions?
Posted by Pete Gonzalez <pg...@bluel.com>.
At 06:00 PM 7/28/2004, you wrote:
>>my proposal: Instead of worrying about hook scripts, why don't we just
>>expand svnserve's authentication model? In other words, we can implement
>>for svnserve a small subset of what WebDAV is doing. This should be an
>>inexpensive way to extend the old model until a proper ACL mechanism
>>is designed. I mean shit, svnserve could probably do this using
>>properties. So... how much work would this be? :-)
>
>I have no idea how much work it would be to do that, but I suspect it
>would touch a significant part of our FS library -- effectively
>duplicating exactly the same amount of work (and intrusiveness) as needed
>for read hooks -- or real ACLs, for that matter.
No no, I mean these checks would be implemented in serve.c (or thereabouts),
as opposed to integrating them directly into the repository/filesystem
libraries. Maybe I'm being overly simplistic here, but this is the picture
in my head (granted I haven't looked very closely at the code):
A. svn --> Apache --> Repository --> FileSystem
B. svn --> svnserve --> Repository --> FileSystem
C. svn --> Repository --> FileSystem
Inside the "Apache" box is a fairly elaborate security model. Inside
the "svnserve" box is a little text file containing some plaintext
passwords and a few buffer overflows for good measure. (Scenario C
is the fabled "SSH authentication" case from CVS, where you pass
a triple security check and retinal scan to end up in a dimly lit
prison cell, wherein you can bend the Berkley database over a table
and do whatever you like, but everyone knows it was you.)
So my question is: If we just want to add a few more security tests
inside the "svnserve" box, why would this involve the Repository or
FileSystem boxes?
Thanks,
-Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Hook scripts -- no support for permissions?
Posted by Branko Čibej <br...@xbc.nu>.
Pete Gonzalez wrote:
> My focus here is much more immediate; although I may have time to write
> some C code, I want to avoid complicated design discussions. So here's
> my proposal: Instead of worrying about hook scripts, why don't we just
> expand svnserve's authentication model? In other words, we can implement
> for svnserve a small subset of what WebDAV is doing. This should be an
> inexpensive way to extend the old model until a proper ACL mechanism
> is designed. I mean shit, svnserve could probably do this using
> properties. So... how much work would this be? :-)
A lot, if you take into account that we'd have to maintain backward
compatibility for such a scheme (that used repository metadata) for
ages. It might be easier to get svnserve to understand the access
control files used by mod_authz_svn (and not mod_dav_svn, as you seem to
believe -- the DAV module does neither authentication nor
auhtorization), so that both mechanisms could use the same access
control configuration.
I have no idea how much work it would be to do that, but I suspect it
would touch a significant part of our FS library -- effectively
duplicating exactly the same amount of work (and intrusiveness) as
needed for read hooks -- or real ACLs, for that matter.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Hook scripts -- no support for permissions?
Posted by Pete Gonzalez <pg...@bluel.com>.
At 10:09 PM 7/23/2004, you wrote:
>Read-hooks are hard to do, which is why we haven't implemented them
>yet. There are *many* read functions in the repository filesystem API
>(svn_fs.h). To implement read hooks, we'd have to "wrap" every one of
>these functions with libsvn_repos functions, and then have every program
>in the world use svn_repos.h instead of svn_fs.h for reading data.
>Messy.
I think what you are saying is that the filesystems are not encapsulated
behind the repository formalism, i.e. Subversion's design treats the
underlying database as a sort of "neighborhood bicycle" subject to
the whimsy of whatever higher-level module wants to go rooting through
its data structures. This makes a lot of sense in the context of the
original mentality, where the high-level interface to Subversion
is WebDAV, and WebDAV's feature set can thus be leveraged for
authentication, the user list, etc. In this mindset, svnserve exists
only as a consolation or marketing tool for amateurs who ask things
like "Why should I have to administer a web server in order to do
version control?" :-)
>We've even had talks about writing persistent daemons to speed up the
>fictional 'read' checks, lest things get too slow. The conversation
>gets messy. If you really want to talk about the design
Exactly; in order to solve these problems correctly, the user list
and authentication model will have to be changed so Subversion can
manage them independently of WebDAV. In fact, you alluded to something
like this in the svn-design document:
>>"For example, someday a hypothetical svn-acl property might hold
>>an access control list which the Subversion server uses to regulate
>>access to repository files."
My focus here is much more immediate; although I may have time to write
some C code, I want to avoid complicated design discussions. So here's
my proposal: Instead of worrying about hook scripts, why don't we just
expand svnserve's authentication model? In other words, we can implement
for svnserve a small subset of what WebDAV is doing. This should be an
inexpensive way to extend the old model until a proper ACL mechanism
is designed. I mean shit, svnserve could probably do this using
properties. So... how much work would this be? :-)
Cheers,
-Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Ignore
Posted by Maarten | AI <mj...@ai.rug.nl>.
Does anyone know how to add a dir in the repository to an ignore list, so
that any working copy trying to update or commit files in this list will not
invoke any changes in the repository?
I don't want to do this for every working copy perse.
Maarten
-----Oorspronkelijk bericht-----
Van: Ben Collins-Sussman [mailto:sussman@collab.net]
Verzonden: zaterdag 24 juli 2004 4:10
Aan: Pete Gonzalez
CC: users@subversion.tigris.org
Onderwerp: Re: Hook scripts -- no support for permissions?
On Fri, 2004-07-23 at 19:36, Pete Gonzalez wrote:
> I would like to prevent certain users from accessing certain
> directories in my repository. (Note: we are using "svnserve"
> instead of the WebDAV quagmire.) I realize that full ACL
> permissions are way off the radar, as Subversion is still
> in its infancy. (*) However, I noticed a hook script called
> "start-commit" that can be used to implement poor man's
> ACL permissions for commits.
>
We already have mod_authz_svn for controlling read/write access on
individual directories. As long you're using apache as your server,
you're set to go. (And someday svnserve will probably grow the same
feature.)
If you're using svnserve, as you say, there's no way to get fine-grained
read access right now.
> I am wondering, how difficult would it be to implement something
> similar for *viewing* files in the repository?
Read-hooks are hard to do, which is why we haven't implemented them
yet. There are *many* read functions in the repository filesystem API
(svn_fs.h). To implement read hooks, we'd have to "wrap" every one of
these functions with libsvn_repos functions, and then have every program
in the world use svn_repos.h instead of svn_fs.h for reading data.
Messy.
It was much easier to implement write hooks: libsvn_repos only had to
wrap two functions: svn_fs_create_txn() and svn_fs_commit_txn(). And
it's an easy burden on programs accessing the repository to use the 2
libsvn_repos wrappers.
We've even had talks about writing persistent daemons to speed up the
fictional 'read' checks, lest things get too slow. The conversation
gets messy. If you really want to talk about the design, come over to
the dev@ list. ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Hook scripts -- no support for permissions?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-07-23 at 19:36, Pete Gonzalez wrote:
> I would like to prevent certain users from accessing certain
> directories in my repository. (Note: we are using "svnserve"
> instead of the WebDAV quagmire.) I realize that full ACL
> permissions are way off the radar, as Subversion is still
> in its infancy. (*) However, I noticed a hook script called
> "start-commit" that can be used to implement poor man's
> ACL permissions for commits.
>
We already have mod_authz_svn for controlling read/write access on
individual directories. As long you're using apache as your server,
you're set to go. (And someday svnserve will probably grow the same
feature.)
If you're using svnserve, as you say, there's no way to get fine-grained
read access right now.
> I am wondering, how difficult would it be to implement something
> similar for *viewing* files in the repository?
Read-hooks are hard to do, which is why we haven't implemented them
yet. There are *many* read functions in the repository filesystem API
(svn_fs.h). To implement read hooks, we'd have to "wrap" every one of
these functions with libsvn_repos functions, and then have every program
in the world use svn_repos.h instead of svn_fs.h for reading data.
Messy.
It was much easier to implement write hooks: libsvn_repos only had to
wrap two functions: svn_fs_create_txn() and svn_fs_commit_txn(). And
it's an easy burden on programs accessing the repository to use the 2
libsvn_repos wrappers.
We've even had talks about writing persistent daemons to speed up the
fictional 'read' checks, lest things get too slow. The conversation
gets messy. If you really want to talk about the design, come over to
the dev@ list. ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org