Svn revert and file permissions bug

[Captain Hypertext <ca...@gmail.com>]

I have a really weird problem which may be a bug.


I'm running Debian 9 with svn 1.8.17, but I also tried with svn 1.9.5,
which I guess is the latest version supported by our OS. Basically, I'm
tasked with updating the permission structure of our application servers
because we've been using root for years to do everything. We have an svn
repo where all the files are owned by the root user.


If I change the file ownership (I'm talking about the working copy files)
to apache:devops, so owned by user apache and group devops, and I run "svn
revert -R .", it lists out every single file. Nothing changes, it just says
"Reverted xxx.php" for every file, every time I run it.  Run "svn revert -R
." again, same thing happens. None of the files have changed at all, and
root has write permissions. If there are local changes in the working copy,
they will be reverted along with all this.


This appears to be happening when svn thinks that my user doesn't have
write permissions to the file. It looks like svn is trying to calculate the
permissions of the files by itself, and isn't factoring in root powers, ACL
(setfacl), or supplemental user groups. So if I set a file's permissions to
666 instead of 664, it doesn't get spit out as reverted. Also, if my user
owns the file (this applies to root too) or my primary group owns the file,
it doesn't spit that file out. But being that a second group I’m a member
of owns the file, it gets spit out.


Can anyone speak to this? Any help is appreciated.


Jeremy

Re: Svn revert and file permissions bug

[Nathan Hartman <ha...@gmail.com>]

On Thu, Aug 13, 2020 at 9:32 AM Captain Hypertext
<ca...@gmail.com> wrote:
> I'm running Debian 9 with svn 1.8.17, but I also tried with svn 1.9.5, which I guess is the latest version supported by our OS. Basically, I'm tasked with updating the permission structure of our application servers because we've been using root for years to do everything. We have an svn repo where all the files are owned by the root user.
>
>
> If I change the file ownership (I'm talking about the working copy files) to apache:devops, so owned by user apache and group devops, and I run "svn revert -R .", it lists out every single file. Nothing changes, it just says "Reverted xxx.php" for every file, every time I run it.  Run "svn revert -R ." again, same thing happens. None of the files have changed at all, and root has write permissions. If there are local changes in the working copy, they will be reverted along with all this.
>
>
> This appears to be happening when svn thinks that my user doesn't have write permissions to the file. It looks like svn is trying to calculate the permissions of the files by itself, and isn't factoring in root powers, ACL (setfacl), or supplemental user groups. So if I set a file's permissions to 666 instead of 664, it doesn't get spit out as reverted. Also, if my user owns the file (this applies to root too) or my primary group owns the file, it doesn't spit that file out. But being that a second group I’m a member of owns the file, it gets spit out.
>
>
> Can anyone speak to this? Any help is appreciated.

Hi,

This looks a lot like: https://issues.apache.org/jira/browse/SVN-4622

However, there is no need to involve the root user. I arrived at a
similar result on my Debian box with SVN 1.10.4. The reproduction
steps are very simple: Just check out a working copy as your normal
user and then change the ownership of a file:

$ svn co https://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts
A    hook-scripts/mailer
A    hook-scripts/mailer/tests
A    hook-scripts/validate-files.py
A    hook-scripts/mailer/mailer.conf.example
A    hook-scripts/mailer/mailer.py
A    hook-scripts/mailer/tests/mailer-init.sh
A    hook-scripts/mailer/tests/mailer-t1.output
A    hook-scripts/mailer/tests/mailer.conf
A    hook-scripts/mailer/tests/mailer-t1.sh
A    hook-scripts/mailer/tests/mailer-tweak.py
A    hook-scripts/CVE-2017-9800-pre-commit.py
A    hook-scripts/reject-detected-sha1-collisions.sh
A    hook-scripts/reject-known-sha1-collisions.sh
A    hook-scripts/svn2feed.py
A    hook-scripts/svnperms.py
A    hook-scripts/control-chars.py
A    hook-scripts/validate-files.conf.example
A    hook-scripts/persist-ephemeral-txnprops.py
A    hook-scripts/validate-extensions.py
A    hook-scripts/commit-email.rb
A    hook-scripts/svnperms.conf.example
A    hook-scripts/log-police.py
A    hook-scripts/verify-po.py
A    hook-scripts/commit-access-control.pl.in
A    hook-scripts/commit-access-control.cfg.example
 U   hook-scripts
Checked out revision 1880841.
$ cd hook-scripts/
$ sudo chown nobody svnperms.conf.example
$ ls -al
total 128
drwxr-xr-x 4 nate   nate  4096 Aug 13 23:32 .
drwxr-xr-x 4 nate   nate  4096 Aug 13 23:32 ..
-rw-r--r-- 1 nate   nate  2984 Aug 13 23:32 commit-access-control.cfg.example
-rwxr-xr-x 1 nate   nate 11766 Aug 13 23:32 commit-access-control.pl.in
-rwxr-xr-x 1 nate   nate  3102 Aug 13 23:32 commit-email.rb
-rwxr-xr-x 1 nate   nate  4355 Aug 13 23:32 control-chars.py
-rwxr-xr-x 1 nate   nate  2841 Aug 13 23:32 CVE-2017-9800-pre-commit.py
-rwxr-xr-x 1 nate   nate  5192 Aug 13 23:32 log-police.py
drwxr-xr-x 3 nate   nate  4096 Aug 13 23:32 mailer
-rwxr-xr-x 1 nate   nate  2352 Aug 13 23:32 persist-ephemeral-txnprops.py
-rwxr-xr-x 1 nate   nate  1750 Aug 13 23:32 reject-detected-sha1-collisions.sh
-rwxr-xr-x 1 nate   nate  1797 Aug 13 23:32 reject-known-sha1-collisions.sh
drwxr-xr-x 4 nate   nate  4096 Aug 13 23:32 .svn
-rwxr-xr-x 1 nate   nate 16726 Aug 13 23:32 svn2feed.py
-rw-r--r-- 1 nobody nate  3147 Aug 13 23:32 svnperms.conf.example
-rwxr-xr-x 1 nate   nate 13243 Aug 13 23:32 svnperms.py
-rwxr-xr-x 1 nate   nate  3516 Aug 13 23:32 validate-extensions.py
-rw-r--r-- 1 nate   nate  3409 Aug 13 23:32 validate-files.conf.example
-rwxr-xr-x 1 nate   nate  6669 Aug 13 23:32 validate-files.py
-rwxr-xr-x 1 nate   nate  3954 Aug 13 23:32 verify-po.py
$ svn revert -R .
Reverted 'svnperms.conf.example'
$ svn revert -R .
Reverted 'svnperms.conf.example'
$ svn revert -R .
Reverted 'svnperms.conf.example'

When reverting, nothing seems to change about the file or its
metadata. It remains owned by user 'nobody' after reverting (which is
as I'd expect).

Permissions do play a big role. Change the file's permissions to 664
and we no longer see output from 'svn revert':

$ sudo chmod 664 svnperms.conf.example
$ ls -l svnperms.conf.example
-rw-rw-r-- 1 nobody nate 3147 Aug 13 23:32 svnperms.conf.example
$ svn revert -R .

(no output here)

But change it back to 644, and we get the output again:

$ sudo chmod 644 svnperms.conf.example
$ ls -l svnperms.conf.example
-rw-r--r-- 1 nobody nate 3147 Aug 13 23:32 svnperms.conf.example
$ svn revert -R .
Reverted 'svnperms.conf.example'

I'm not sure whether this is an actual bug in SVN or just a
consequence of ownership/permissions. If it's a bug, the bug might be
that we're generating a misleading output, since nothing was reverted.

As I understand from your description, you're using SVN to track your
server setup. I've heard of SVN being used this way, but I've never
used it this way myself. Hopefully someone with experience in that
area could chime in here as to how they manage the permissions of the
tracked files.

One idea might be to write an initialization script that is run
immediately after making a fresh checkout. This script would set the
ownership and permissions of all the files to their appropriate
values. The script itself would be under version control so as to keep
it in sync with the files.

Nathan