Remove uid/gid from wsrep_sst_rsync | Rsync 3.1.0 - rsync: setgroups failed: Operation not permitted

a) As per

ftp://ftp.ulakbim.gov.tr/pub/rsync/nightly/rsyncd.conf.html

" The default for a non-super-user is to not try to change the user."

" The default for a non-super-user is to not change any group attributes (and indeed, your OS may not allow a non-super-user to try to change their group settings)."

Since mysqld (and hence wsrep-sst-rsync and rsync) run as non-super users, there shouldn't be a problem here.

b)
I also tested with rsync 3.1.0 and older, without uid/gid
specified, it indeed runs as uid/gid of mysqld user.

c)
I also tested with rsync 3.1.0 with uid and gid added.

and it failed as:

Dec 17 14:55:08 Archie rsyncd[36948]: rsyncd version 3.1.0 starting, listening on port 5001
Dec 17 14:55:08 Archie rsyncd[36991]: connect from localhost.localdomain (127.0.0.1)
Dec 17 14:55:08 Archie rsyncd[36991]: rsync: setgroups failed: Operation not permitted (1)

Following is what happens:

  if (setgroups(gid_count, gid_list)) {
   rsyserr(FLOG, errno, "setgroups failed");
   io_printf(f_out, "@ERROR: setgroups failed\n");
   return -1;
  }

and from setgroups(2)

"
setgroups() sets the supplementary group IDs for the calling process. Appropriate privileges (Linux: the CAP_SETGID capability) are required.
"

Either CAP_SETGID is required on rsync binary or only the admin (root) user can do this, which explains why it fails for mysqld.

As for setuid/setguid done by mysqld (as root to setuid as --user
user)in set_user, it is invoked before SST is done, so uid and euid for
wsrep-sst-rsync are essentially that of mysqld (they are inherited), so
wsrep-sst-rsync also runs with euid = uid = mysqld user.

Fixes pushed in
http://bazaar.launchpad.net/~codership/codership-mysql/wsrep-5.5/revision/3959
http://bazaar.launchpad.net/~codership/codership-mysql/5.6/revision/4051

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXC-1555