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

RE: svnadmin create makes bad file permissions

From: Tom Malia <tommalia_at_ttdsinc.com>
Date: 2007-03-30 15:35:39 CEST

I have no idea what:
sudo -u apache svnadmin create repo

does.

Is this a UNIX thing?

-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2007a@ryandesign.com]
Sent: Friday, March 30, 2007 9:27 AM
To: Tom Malia
Cc: 'Zig'; users@subversion.tigris.org
Subject: Re: svnadmin create makes bad file permissions

On Mar 30, 2007, at 06:27, Tom Malia wrote:

>>> So I just set up subversion on my gentoo slice. I'm using the
>>> custom svnserve provided with subversion for now because it seemed
>>> quickest and easiest. This problem is probably not specific to this
>>> choice of server though.
>>>
>>> So in gentoo, svnserve runs as user:group apache:apache, as can be
>>> seen in /etc/init.d/svnserve (or overridden in /etc/conf.d/
>>> svnserve). However, when I create a repository using sudo svnadmin
>>> create /var/svn/whatever, the repository gets created with
>>> root:root permissions. Thus when I tried to do a commit, I get an
>>> error like "Can't create directory '/var/svn/whatever/db/
>>> transactions/0-1.txn': Permission denied" (though I can checkout
>>> the repository just fine. I guess the repository has world read
>>> access but only root write access). I can fix this either by
>>> setting svnserve to run as root, or else (which is preferable) by
>>> changing the permissions (chown -R apache:apache /var/svn/
>>> whatever). I tried both but and went with the latter and now it
>>> works fine.
>>>
>>> Since I prefer the second method (I don't want svnserve to run as
>>> root unless it has to, and I probably will eventually want to use
>>> apache instead of svnserve), it would be highly desirable to get
>>> svnadmin to create repositories owned by apache by default. Does
>>> svnadmin have any smartness about the permissions and ownerships of
>>> the repository files it creates?
>>>
>>> I've just searched through the archives of this mailing list, and
>>> I've seen a few short discussions about this error, and the only
>>> solution seems to be some chowning (perhaps followed by some
>>> chmodding). Surprisingly, the subversion books seems not to breath
>>> a word about file ownership in the chapter about creating
>>> repositories.
>>>
>>> Anyway, I'd very much like svnadmin to be smart about this. Is
>>> it? Or do I just have to resign myself to monkeying with
>>> permissions every time I create a repository?
>>
>> You have to monkey with the permissions every time you create a
>> repository. Isn't that fairly usual behavior for Unix software
>> though?
>
> I had a similar gripe but was really hoping that I just hadn't yet
> stumbled
> across the documentation that told you how to create "template"
> configuration files. What I was thinking would be nice is, if
> there was
> some way you could create access rights and configuration files
> that you
> could use as "templates" then when you do the create either it
> would always
> look in a predefined location to find such templates, or there
> would be some
> command line switches you could use to point it at such templates.
> Does
> this sound to others like a possibly reasonable approach to this
> issue? If
> so, do you think it would be a reasonable feature request?

Wouldn't something like...

sudo -u apache svnadmin create repo

...take care of the original problem without needing to modify
Subversion?

Or are you asking for something different with "templates"?

-- 
To reply to the mailing list, please use your mailer's Reply To All  
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 30 15:36:07 2007

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.