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

Re: Needed 'chmod 777' to allow remote commit via http ?

From: Kevin Galligan <mailinglists_at_kgalligan.com>
Date: 2006-04-17 15:38:41 CEST

Thought I replied to the users group but instead it was directly to you. I
think I should open this up to the general board.

To preface, I'm not a unix expert, but I've done this recently, and I think
I have the general idea right.

Essentially, the issue with '774' is that you're setting execute on many
files that should not have execute. As stated in my previous, it should be
'755' on directories, and '644' on files, or something along those lines.
You need execute on the directories but not the files. It means different
things to directories and to files.

I would recreate the whole repository, as stated in my other message...

svnadmin create newdocuments
svnadmin dump documents | svnadmin load newdocuments
chown -R apache:apache newdocuments
mv documents olddocuments
mv newdocuments documents

Looking at my repository it seemed 'svnadmin create' left sensible defaults.

On 4/17/06, Bruno Costacurta <cob1@biz.tiscali.be> wrote:
>
> Indeed some chmod are needed.
> Security is managed via svn/apache setup but also via operating system.
> (which looks logical as the operating system manage user/groups for files
> access).
> I 'chmod -R 774' on svn/repos directory and now can access via user
> defined d
> in svn/apache config from remote place for read and also write.
> I suppose this can be fine tuned (ie. write acces are only needed on
> db/directory).
>
> Bye,
> Bruno
>
> On Sunday 16 April 2006 18:11, you wrote:
> > As a non-expert in *-nix, but having recently done this, I think you
> need
> > to change the owner of the directory/files.
> >
> > If the user that apache runs under is 'apache', for example, it would
> be...
> >
> > chown -R apapche:apache /usr/local/svn/repos/documents
> >
> > You should also change back your file permissions. This I would have
> some
> > trouble with because directory permissions should be somewhat different
> > than file permissions (as I understand it). But essentially it would
> be...
> >
> > chmod 755 [directory]
> > chmod 644 [file]
> >
> > I don't know how to apply recursively to directories and files
> only. You
> > don't want execute on files, but you do on directories.
> >
> > On my system the apache user is 'www-data'. I don't know how common
> that
> > is. I hadn't seen that in the docs. I'm running ubuntu, which is a
> debian
> > variant.
> >
> > On 4/16/06, Bruno Costacurta <cob1@biz.tiscali.be> wrote:
> > > Hello To All,
> > > do I need a 'chmod -R 777 /usr/local/svn/' to allow access from remote
> > > client ?
> > >
> > > I setup Apache2 and related files.
> > > Everything works from remote access via http (ie. http://..etc.. and
> svn
> > > checkout http://..etc.. are ok from remote PC)
> > > but I was not able to commit files because of permission denied on
> > > directory ../db/transactions/*
> > >
> > > I resolved this via a chmod -R 777.
> > > But is this mandatory ? chmod 777 is not secure and would like to
> avoid.
> > > How to proceed ?
> > >
> > > My config:
> > > file httpd.conf:
> > > ...
> > > <Location /usr/local/svn/repos/documents>
> > > DAV svn
> > > SVNPath /usr/local/svn/repos/documents
> > > AuthType Basic
> > > AuthName "Subversion Repository"
> > > AuthUserFile /etc/httpd/passwd/passwords
> > > AuthzSVNAccessFile /etc/httpd/passwd/svnauthz.conf
> > > Require valid-user
> > > </Location>
> > > ...
> > >
> > > file passwords :
> > > [/]
> > > bruno = rw
> > >
> > >
> > > Thanks for attention.
> > > Bye,
> > > Bruno
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > > For additional commands, e-mail: users-help@subversion.tigris.org
>
Received on Mon Apr 17 15:39:57 2006

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.