rsync - Jul 2015 - [Bug 11414] New: rsync: chgrp "/.filename.5afK5X" (in dirdir) failed: Operation not permitted (1)

https://bugzilla.samba.org/show_bug.cgi?id=11414

            Bug ID: 11414
           Summary: rsync: chgrp "/.filename.5afK5X" (in dirdir)
failed:
                    Operation not permitted (1)
           Product: rsync
           Version: 3.1.1
          Hardware: x64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
          Assignee: wayned at samba.org
          Reporter: nhannguyen at 0937686468.com
        QA Contact: rsync-qa at samba.org

Notice : With The configuration file below in version 3.0.6,it is working . 
-----------------------------------------------------------------------------


-My rsync's config (rsyncd.conf):
=========================================lock file = /var/run/rsync.lock
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
ignore errors= true
uid = sfftp
gid = sfftp
reverse lookup = no
[9tlocal]
path=/sfarm/9tlocal/
uid = www
gid = www
auth users = 9tlocal
secrets file = /etc/rsyncd.secrets
read only = no
log file = /var/log/rsyncd9tlocal.log
===========================================
However I got a problem with rsync daemon on version 3.1.1:

When I execute this cmd :
rsync -avz --progress --delete /data/client/ 9tlocal at 10.76.0.195::9tlocal

It sync data to dir /sfarm/9tlocal/ but It show these error log:
rsync -avz --progress --delete /data/client/ 9tlocal at 10.76.0.195::9tlocal
Password: 
sending incremental file list
rsync: chgrp "/." (in 9tlocal) failed: Operation not permitted (1)
rsync: failed to open "/syn_pre_update.log" (in 9tlocal), continuing:
Permission denied (13)
rsync: failed to open "/test" (in 9tlocal), continuing: Permission
denied (13)
./
syn_pre_update.log
          2,017 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=1/3)
test
  1,073,741,824 100%   63.80MB/s    0:00:16 (xfr#2, to-chk=0/3)
rsync: chgrp "/.syn_pre_update.log.4kTDrH" (in 9tlocal) failed:
Operation not
permitted (1)
rsync: chgrp "/.test.yVQDby" (in 9tlocal) failed: Operation not
permitted (1)

sent 1,044,817 bytes  received 486 bytes  27,874.75 bytes/sec
total size is 1,073,743,841  speedup is 1,027.21
rsync error: some files/attrs were not transferred (see previous errors) (code
23) at main.c(1165) [sender=3.1.1]

ls -al /data/client/
total 1048592
drwxr-xr-x 2 root root       4096 Th07 27 14:07 .
drwxr-xr-x 3 root root       4096 Th07 27 11:17 ..
-rw-r--r-- 1 root root       2017 Th07 27 14:07 syn_pre_update.log
-rw-r--r-- 1 root root 1073741824 Th07 24 14:34 test



ls -al /sfarm/9tlocal/
total 1048592
drwxr-xr-x 2 www www        4096 Th07 27 14:07 .
drwxr-xr-x 5 root    root       4096 Th07 27 11:25 ..
-rw------- 1 www www        2017 Th07 27 14:58 syn_pre_update.log
-rw------- 1 www www  1073741824 Th07 27 14:58 test


==========================================================Finally I re-run cmd
with below option(replace option -a by -r )it's OK :

rsync -rvz --progress --delete /data/client/ 9tlocal at 10.76.0.195::9tlocal

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=11414

Nguyen Si Nhan <nhannguyen at 0937686468.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #1 from Nguyen Si Nhan <nhannguyen at 0937686468.com> ---
When I add this line to rsyncd.conf it's ok:
fake super = yes

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=11414

--- Comment #2 from Michal Ruprich <mruprich at redhat.com> ---
I stumbled upon this bug and I have a question. I get the chgrp error even when
running the daemon as root. 

#ps -aux | grep rsync
root     18486  0.0  0.0 114696   568 ?        Ss   09:41   0:00 rsync --daemon

I have configured a module in /etc/rsyncd.conf like this:
[my_data]
    comment = test dir for rsync
    path = /home/tester
    read only = no
    uid = tester
    gid = tester

Now when I try to copy file 'data' to this module:
# rsync -av data localhost::my_data
sending incremental file list
data
rsync: chgrp "/.data.CFttwz" (in my_data) failed: Operation not
permitted (1)

sent 86 bytes  received 117 bytes  406.00 bytes/sec
total size is 0  speedup is 0.00
rsync error: some files/attrs were not transferred (see previous errors) (code
23) at main.c(1178) [sender=3.1.2]

This doesn't happen with version 3.0.9. And I think that this should not
happen. It works fine with the 'fake super' option set to 'yes'
but the daemon
runs under root and the fake super option says: "This allows the full
attributes of a file to be stored without having to have the daemon actually
running as root." From this description I would assume that you don't
need the
'fake super' option to transfer all attributes when the daemon runs
under root
right?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

It isn't running as root (it probably never should).  It is launched as
root.  It is running as tester:tester just like you set it to.

On 11/06/2017 10:31 AM, just subscribed for rsync-qa from bugzilla via
rsync wrote:
> https://bugzilla.samba.org/show_bug.cgi?id=11414
> 
> --- Comment #2 from Michal Ruprich <mruprich at redhat.com> ---
> I stumbled upon this bug and I have a question. I get the chgrp error even
when
> running the daemon as root. 
> 
> #ps -aux | grep rsync
> root     18486  0.0  0.0 114696   568 ?        Ss   09:41   0:00 rsync
--daemon
> 
> I have configured a module in /etc/rsyncd.conf like this:
> [my_data]
>     comment = test dir for rsync
>     path = /home/tester
>     read only = no
>     uid = tester
>     gid = tester
> 
> Now when I try to copy file 'data' to this module:
> # rsync -av data localhost::my_data
> sending incremental file list
> data
> rsync: chgrp "/.data.CFttwz" (in my_data) failed: Operation not
permitted (1)
> 
> sent 86 bytes  received 117 bytes  406.00 bytes/sec
> total size is 0  speedup is 0.00
> rsync error: some files/attrs were not transferred (see previous errors)
(code
> 23) at main.c(1178) [sender=3.1.2]
> 
> This doesn't happen with version 3.0.9. And I think that this should
not
> happen. It works fine with the 'fake super' option set to
'yes' but the daemon
> runs under root and the fake super option says: "This allows the full
> attributes of a file to be stored without having to have the daemon
actually
> running as root." From this description I would assume that you
don't need the
> 'fake super' option to transfer all attributes when the daemon runs
under root
> right?
> 
-- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			http://www.sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 224 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20171106/b7e91ed9/signature.sig>

https://bugzilla.samba.org/show_bug.cgi?id=11414

--- Comment #3 from Kevin Korb <rsync at sanitarium.net> ---
Oops, I replied to this on the email list instead of the bugzilla.  Sorry for
the extra noise...

It isn't running as root (it probably never should).  It is launched as
root.  It is running as tester:tester just like you set it to.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=11414

--- Comment #4 from Michal Ruprich <mruprich at redhat.com> ---
I see. I never looked at the ps aux output during the transfer so all I saw was
the user that launched the daemon. So I assume that the chgrp error that occurs
without the fake super option is the correct behaviour and the previous version
did this wrong?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=11414

--- Comment #5 from Michal Ruprich <mruprich at redhat.com> ---
There is one more thing that doesn't make sense to me. Even if the operation
of
changing the group fails, why doesn't rsync finish other things under the -a
option. For instance the permissions of the original file are 0644 and if the
chgrp error occurs, the destination permissions are just 0600. The user tester
owns the destination file and it should be able to change the permissions.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=11414

--- Comment #6 from Kevin Korb <rsync at sanitarium.net> ---
There was a change made in 3.1.0...

    - Added a way for more than one group to be specified in the daemon's
      config file, including a way to specify that you want all of the
      specified user's groups without having to name them.  Also changed the
      daemon to complain about an inability to set explicitly-specified uid/gid
      values, even when not run by a super-user.

So, even if a user is in more than one group once you set the gid option the
listed groups are all that user gets to be in now.

I am not sure if the lack of permission setting is a bug or an rsyncd feature
and I don't know if it is still the case in the current version.  I
don't
really feel like setting up a test case to find out.  IMO if you are running
rsyncd without read only = yes and/or withe authentication you are mis-using
rsyncd.  If you want these things use rsync over ssh where you have decent
authentication+security.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=11414

--- Comment #7 from Michal Ruprich <mruprich at redhat.com> ---
Thank you Kevin. This makes sense.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.