[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: File Permissions

From: Vincent Lefevre <vincent+svn_at_vinc17.org>
Date: Wed, 4 Jun 2008 15:23:38 +0200

On 2008-06-04 11:00:14 +0200, Marc Haisenko wrote:
> The client hook would of course allow to implement something like
> that, but that issue has also been discussed already, as far as I
> remember, and I think the developers thought it might not be a good
> idea (but please search the archive yourself, I'm not entirely
> sure). You care about just yourself, and seem to assume that you
> will be the only user of that specific repository.

But this would be one of the goal of client-side hooks: each user
does whatever he wants with them. The user could also check that
updated XML files are well-formed/valid if he wants to, update
other files (not managed by Subversion) if some file is modified
(e.g. to update an index), and so on.

Also, as I've said, such a feature would be useful mainly for users
who manage their own files with Subversion; so yes, in these cases,
the user cares about himself and is the only user of the repository.
Not all repositories have to use client-side hooks after all!

Note that concerning user-side (client-side) configuration, this
is already the case of umask: Subversion doesn't enforce an umask
value specified at the repository level, so that different users
can already end up with different permissions. I don't see such a
feature very different to what client-side hooks could provide.

> The SubVersion developers have to think a bit bigger and then issues
> that are none to you become huge. One issue would be: Where would
> those hooks be stored ?

In the ~/.subversion directory, for instance.

> If every user has to install the hook himself

Yes, every user *must* install the hook himself.

> then inconsistencies can occur (e.g. not every user has that hook,
> maybe they have different versions, etc. pp.).

Client-side hooks should be optional. So, fatal inconsistencies
would be an error from the users.

> If the hooks are stored in the repository you have a huge security
> desaster

Of course. That's why the user must install hooks himself. The hook
can also contain code to update itself (e.g. if a copy is stored in
the repository); of course, in such a case, there would be security
implications if the repository is shared by several users (i.e. it
is not a repository for the user's own files), but there are also
security implications by typing "make" in a development project
managed by Subversion (or any other VCS).

BTW, about the security, a client-side hook could also do some
checks on the files that have been updated, e.g. the presence of
a virus or suspicious code. Such a feature isn't that bad, is it?

> So if all you need that feature for is archiving some stuff (like
> you /etc directory) you are better off using an external script like
> the "asvn" script already present,

You didn't take into account the problems I mentioned about asvn:
  * it is inefficient because it doesn't know which files have been
  * it doesn't fix the permissions in real time (this point is less
IMHO, these two problems can only be solved cleanly with client-side
hooks or something similar, i.e. with some feedback given by svn.
Well, if someone knows how to parse its output without any drawback
(there are often problems with signals[1] and/or buffering[2]), then
I think this could be a solution too (though I'd prefer client-side

[1] This one, for instance:

[2] Well, it seems that buffering should not be a problem since 1.4.0
as I can see

  * flush stdout after each status/notification line (r19476 -656)

in the CHANGES file. But it is listed under "Developer-visible changes".
So, I wonder...

Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-04 15:24:05 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.