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

Re: .svn/wc.db as group writable

From: Carlos Adean <carlosadean_at_linea.gov.br>
Date: Wed, 15 Mar 2017 10:34:43 -0300 (BRT)

----- Mensagem original -----
> De: "Branko Čibej" <brane_at_apache.org>
> Para: users_at_subversion.apache.org
> Enviadas: Quinta-feira, 23 de fevereiro de 2017 22:03:28
> Assunto: Re: .svn/wc.db as group writable
>
> On 23.02.2017 23:59, Stefan wrote:
> > On 2/22/2017 17:13, Carlos Adean wrote:
> >> Hello,
> >>
> >>
> >> ----- Mensagem original -----
> >>> De: "Stefan Hett" <stefan_at_egosoft.com>
> >>> Para: users_at_subversion.apache.org
> >>> Enviadas: Segunda-feira, 20 de fevereiro de 2017 12:03:36
> >>> Assunto: Re: .svn/wc.db as group writable
> >>>
> >>> On 2/20/2017 1:40 PM, Carlos Adean wrote:
> >>>
> >>>
> >>>
> >>>
> >>> On the specific issue: I'm not getting completely what problem
> >>> you
> >>> are
> >>> facing. Are you expecting that SVN sets the group for .svn/wc.db
> >>> according to some group you set up by itself so it's
> >>> readably/usable
> >>> by
> >>> other users than the one who did the repository checkout?
> >>>
> >>> Regards,
> >>> Stefan
> >>>
> >>>> So, I have set umask 002 and it works for all files except on
> >>>> .svn/wc.db - maybe I'm wrong and this is not a SVN problem.
> >>>>
> >>>>
> >>>> Again, I know this is unusual situation but is how we need to
> >>>> work.
> >>>>
> >>>>> Can you be a bit more specific what exactly you mean by "That's
> >>>>> the
> >>>>> file that causes the problem[...]"? Do you get an SVN error
> >>>>> when you
> >>>>> perform some operation from different accounts on the working
> >>>>> copy
> >>>>> (in that case, please state the exact error message)?
> >>>>> Alternatively:
> >>>>> Are you suggesting that after performing an SVN operation the
> >>>>> permissions of .svn/wc.db are changed (to what they were before
> >>>>> the
> >>>>> call)?
> >> The default umask is 002 for all users and all of them are in the
> >> same group 'appgroup', which is the group that owns the
> >> repositories. The repositories are remote and one specific user
> >> creates local copies/clones. This user checks out a repository in
> >> a given directory (e.g. /home/appuser/software/trunk) using his
> >> own account. If a different user tries to svn update the same
> >> local copy of the repository, he gets errors of the type:
> >>
> >> svn: E155004: Working copy '/home/appuser/software/trunk' locked
> >> svn: E200031: sqlite: attempt to write a readonly database
> >> svn: E200031: sqlite: attempt to write a readonly database
> >> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup'
> >> for details)
> >>
> >> my doubt is: if the umask is 002 why are the permissions for the
> >> group read-only on that file after checkout?
> >>
> > It certainly looks like some permission setup on your environment
> > to me.
> > I don't have a test Linux machine running atm, so I can't test; but
> > I'd
> > assume that files created in the user's home directly by default
> > are
> > only granted full access by the current user, no? [1]
>
> No. They're granted whatever access is allowed by the umask. See
> https://en.wikipedia.org/wiki/Umask
>
> If the umask is 002 then all created files will, by default, allow
> read
> and write access to the user and the user's primary group. Neither
> Subversion nor SQLite tries to be smart in any way in this respect.
>
> There are other ways to control permissions on new files: your
> filesystem could have inheritable ACLs that prevent group-write
> permission to be granted, regardless of umask. Your SELinux
> configuration could do that, too.
>
> In any case, this is not a Subversion bug.
>
> -- Brane
>

Hi folks,

Sorry for the long silence.

The permissions problem 'svn/wc.db as group writable' was solved after updating to the latest v1.9.5.

Thanks,

--
Carlos Adean
IT Team
linea.gov.br
skype: carlosadean
Received on 2017-03-15 14:35:04 CET

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.