----- Mensagem original ----- > De: "Branko Čibej" <br...@apache.org> > Para: users@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" <ste...@egosoft.com> > >>> Para: users@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
