Re: write permission issues with repository hosting

[David Weintraub <qa...@gmail.com>]

On Oct 29, 2010, at 11:41 AM, "Polder, Matthew J" <ma...@lmco.com> wrote:
> We’re running Subversion 1.6.12 on a Solaris 10 machine and hosting repositories on it. Users can create and use repositories via svnadmin and svn locally on the Solaris machine via file:///, or they can check in and out via TortoiseSVN 1.6.8 on their PC via the http:/// protocol, with LDAP verification.
> 
It's very simple. All files in the repository must be read/writeable to the user who is running the server side process. For the file:/// protocol, it's the user doing the checkout. For svn://,it's the user who is running svnserve. For http://, it's the user running httpd. 

The files don't have to be owned by the user. For example, the user might be a member of a group with read/write access. However, when a new revision is written, the new revision will be owned by the user running the server process. 

Normally, you don't use the file:/// protocol except for private repositories. Otherwise, all users can directly manipulate the source repository itself. In fact, I never use file:/// even on my private repository. It's easy enough to run svnserve on my machine. 

Have the svnserve and httpd processes owned by the same user and drop file:/// access. Then chown the files to that user and set permissions on all files to 664. 

--
David Weintraub
David@Weintraub.name
Sent from my iPhone while riding in my Ferrari. (Jealous?)

RE: EXTERNAL: Re: write permission issues with repository hosting

["Polder, Matthew J" <ma...@lmco.com>]

David,

Thanks for your answer from your Ferrari.

We’ve considered using the http protocol locally on the unix machine hosting subversion, but then we either have to always type in our password (we’re using ldap verification) which is annoying, or store the password unencrypted locally in the .subversion/auth directory.

Our problem stems from the http process. When an import or commit is done via http, the dav directory in the repository folder becomes 775 (drwxrwxr-x) but the owner and group is daemon, not the original svn group the repository was created with, so no user in the svn group can thereafter write to the repository.

thanks,
matthew

From: David Weintraub [mailto:qazwart@gmail.com]
Sent: Monday, November 01, 2010 9:36 AM
To: Polder, Matthew J
Cc: users@subversion.apache.org
Subject: EXTERNAL: Re: write permission issues with repository hosting

On Oct 29, 2010, at 11:41 AM, "Polder, Matthew J" <ma...@lmco.com>> wrote:
We’re running Subversion 1.6.12 on a Solaris 10 machine and hosting repositories on it. Users can create and use repositories via svnadmin and svn locally on the Solaris machine via file:///<file:///\\>, or they can check in and out via TortoiseSVN 1.6.8 on their PC via the http:///<http://> protocol, with LDAP verification.
It's very simple. All files in the repository must be read/writeable to the user who is running the server side process. For the file:/// protocol, it's the user doing the checkout. For svn://,it's the user who is running svnserve. For http://, it's the user running httpd.

The files don't have to be owned by the user. For example, the user might be a member of a group with read/write access. However, when a new revision is written, the new revision will be owned by the user running the server process.

Normally, you don't use the file:/// protocol except for private repositories. Otherwise, all users can directly manipulate the source repository itself. In fact, I never use file:/// even on my private repository. It's easy enough to run svnserve on my machine.

Have the svnserve and httpd processes owned by the same user and drop file:/// access. Then chown the files to that user and set permissions on all files to 664.

--
David Weintraub
David@Weintraub.name<ma...@Weintraub.name>
Sent from my iPhone while riding in my Ferrari. (Jealous?)

RE: EXTERNAL: Re: write permission issues with repository hosting

["Polder, Matthew J" <ma...@lmco.com>]

Update:

We made some progress once we updated the Group property in the httpd.conf file as suggested in http://svnbook.red-bean.com/en/1.5/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authn (look up one paragraph). However, now we’re running into Issue 3437, where the rep-cache.db file is created with –rw-r--r--. Anyone have any suggestions how to get around this?

thanks,
matthew

From: Polder, Matthew J
Sent: Monday, November 01, 2010 9:53 AM
To: 'David Weintraub'
Cc: users@subversion.apache.org
Subject: RE: EXTERNAL: Re: write permission issues with repository hosting

David,

Thanks for your answer from your Ferrari.

We’ve considered using the http protocol locally on the unix machine hosting subversion, but then we either have to always type in our password (we’re using ldap verification) which is annoying, or store the password unencrypted locally in the .subversion/auth directory.

Our problem stems from the http process. When an import or commit is done via http, the dav directory in the repository folder becomes 775 (drwxrwxr-x) but the owner and group is daemon, not the original svn group the repository was created with, so no user in the svn group can thereafter write to the repository.

thanks,
matthew

From: David Weintraub [mailto:qazwart@gmail.com]
Sent: Monday, November 01, 2010 9:36 AM
To: Polder, Matthew J
Cc: users@subversion.apache.org
Subject: EXTERNAL: Re: write permission issues with repository hosting

On Oct 29, 2010, at 11:41 AM, "Polder, Matthew J" <ma...@lmco.com>> wrote:
We’re running Subversion 1.6.12 on a Solaris 10 machine and hosting repositories on it. Users can create and use repositories via svnadmin and svn locally on the Solaris machine via file:///<file:///\\>, or they can check in and out via TortoiseSVN 1.6.8 on their PC via the http:///<http://> protocol, with LDAP verification.
It's very simple. All files in the repository must be read/writeable to the user who is running the server side process. For the file:/// protocol, it's the user doing the checkout. For svn://,it's the user who is running svnserve. For http://, it's the user running httpd.

The files don't have to be owned by the user. For example, the user might be a member of a group with read/write access. However, when a new revision is written, the new revision will be owned by the user running the server process.

Normally, you don't use the file:/// protocol except for private repositories. Otherwise, all users can directly manipulate the source repository itself. In fact, I never use file:/// even on my private repository. It's easy enough to run svnserve on my machine.

Have the svnserve and httpd processes owned by the same user and drop file:/// access. Then chown the files to that user and set permissions on all files to 664.

--
David Weintraub
David@Weintraub.name<ma...@Weintraub.name>
Sent from my iPhone while riding in my Ferrari. (Jealous?)

Re: write permission issues with repository hosting

[Nico Kadel-Garcia <nk...@gmail.com>]

On Mon, Nov 1, 2010 at 9:36 AM, David Weintraub <qa...@gmail.com> wrote:

> It's very simple. All files in the repository must be read/writeable to the
> user who is running the server side process. For the file:/// protocol, it's
> the user doing the checkout. For svn://,it's the user who is running
> svnserve. For http://, it's the user running httpd.

And when you run "svnadmin hotcopy", it's entirely ignored and
replicated as whoever does the hotcopy, even if you do it as the root
user. This breaks any management of write permissions for both the
"svn" user and the "apache" user, as might be done for a shared group
with both svn+ssh:// or svn:// access and HTTP access, or direct
file:/// access on the local filesystem, or hook scripts that are
locked and owned by an administrative user.

It's a longstanding problem, exacerbated by the distinct access
requirements of each of the distinct access technologies. It is by no
means "simple".

I've too often had to clean up after this kind of handwaving works,
for a little while, but then breaks as soon as one small factor is
changed.

> The files don't have to be owned by the user. For example, the user might be
> a member of a group with read/write access. However, when a new revision is
> written, the new revision will be owned by the user running the server
> process.
> Normally, you don't use the file:/// protocol except for private
> repositories. Otherwise, all users can directly manipulate the source
> repository itself. In fact, I never use file:/// even on my private
> repository. It's easy enough to run svnserve on my machine.
> Have the svnserve and httpd processes owned by the same user and drop
> file:/// access. Then chown the files to that user and set permissions on
> all files to 664.

This is non-trivial for security reasons. The 'apache' user may run
various back end tools, such as locally built PHP based technologies,
that you do *not* want overwriting or messing with your Subversion
repositories, especially the configuration files, without very careful
thought. Conversely, switching Apache to run as as a designated 'svn'
user can create all sorts of problems with ownership of log files or
working web repositories.