The handling of permissions in rsync (2.5.2) is nasty or broken. (tested platforms: Linux 2.4.x and Solaris 7) We have a directory which should only accessible to a group of users (test) : [sn@noname test]$ ls -lda /home/test drwxrws--- 2 root test 4096 Feb 13 15:44 /home/test Every user has an umask of 007 and his/her own default group: [sn@noname sn]$ id uid=500(sn) gid=500(sn) groups=500(sn),5001(test) Files and directory are created in the right way: [sn@noname test]$ touch /home/test/file ; mkdir /home/test/dir [sn@noname test]$ ls -la /home/test total 12 drwxrws--- 3 root test 4096 Feb 13 15:51 . drwxr-xr-x 8 root root 4096 Feb 13 15:20 .. drwxrws--- 2 sn test 4096 Feb 13 15:51 dir -rw-rw---- 1 sn test 0 Feb 13 15:50 file This works quite nice and I really don't want to mess things up because there is also samba access to this directory. This is the default behaviour of mkdir(2) and open(2). Now there is a readonly, public rsyncd share on the webserver from where I want to mirror into a subdirectory. Files and directories on the rsyncd modul look like this: [sn@noname test]$ rsync webserver::logs/archiv/support/02/02/ drwxr-x--- 4096 2002/02/13 06:02:11 . -rw-r----- 30994 2002/02/13 06:02:11 access-020213.gz -rw-r----- 1644 2002/02/13 06:02:11 error-020213.gz I run rsync to copy the directory: [sn@noname test]$ rsync -r webserver::logs logfiles I didn't get what I expected: The newly created directory "logfiles" is ok: [sn@noname test]$ ls -ld logfiles drwxrws--- 3 sn test 4096 Feb 14 10:52 logfiles One level deeper the group of the directory is good but w and s for group is missing: [sn@noname test]$ ls -ld logfiles/archiv drwxr-x--- 3 sn test 4096 Feb 14 10:52 logfiles/archiv Because s was not set for group on "logfiles/archiv" everything in its subdirectories is wrong: [sn@noname test]$ ls -la logfiles/archiv/support/02/02/ total 44 drwxr-x--- 2 sn sn 4096 Feb 13 16:12 . drwxr-x--- 3 sn sn 4096 Feb 13 16:12 .. -rw-r----- 1 sn sn 30994 Feb 13 16:12 access-020213.gz -rw-r----- 1 sn sn 1644 Feb 13 16:12 error-020213.gz I want: [sn@noname test]$ ls -la logfiles/archiv/support/02/02/ total 44 drwxrws--- 2 sn test 4096 Feb 13 16:24 . drwxrws--- 3 sn test 4096 Feb 13 16:24 .. -rw-rw---- 1 sn test 30994 Feb 13 16:24 access-020213.gz -rw-rw---- 1 sn test 1644 Feb 13 16:24 error-020213.gz Using -p does the expected but not wanted: [sn@noname test]$ rsync -rp webserver::logs logfiles [sn@noname test]$ ls -la logfiles/archiv/support/02/02/ total 44 drwxr-xr-x 2 sn sn 4096 Feb 13 16:21 . drwxr-xr-x 3 sn sn 4096 Feb 13 16:21 .. -rw-r--r-- 1 sn sn 30994 Feb 13 16:21 access-020213.gz -rw-r--r-- 1 sn sn 1644 Feb 13 16:21 error-020213.gz What is rsync doing with permissions when -p is not given? I think it should do nothing. cu, Stefan -- Stefan Nehlsen | ParlaNet Administration | sn@parlanet.de | +49 431 988-1260
This is a "me too". We've just been stung with that too. "rsync -r file remote::module/" appears to mean that the remote copy of "file" indeed ends up with the perms assosiated with the umask of the rsync daemon (as it should). However "rsync -r dir remote::module/" appears to still transmit the permissions of the dir.. In fact, this brings up another issue. What if the rsync server administrator wants to control permissions? What about a new config option "umask = 0770" for instance? That way, irrespective of what options are used by the client, the server controls the permissions; explicitly ensuring the permissions are always set to that value (setting the umask before starting rsync doesn't do the same thing, as this should be settable at the module level). At the moment doesn't there seem to be a bit too much relying on the client to "do the right thing"? -- Cheers Jason Haar Information Security Manager Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417