On Thu, Aug 13, 2020 at 9:32 AM Captain Hypertext <captainhypert...@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
