4

I have a need to copy files between servers through the web. I'm using RSYNC over ssh to do so. The problem is, I need to be able to transfer files, no matter where the files is.

I created a user rsync and : usermod -G root -a rsync to give him the right to read/write anywhere on both servers.

During the transfer, I see this error: 

rsync: mkstemp "/root/.myFile.RDr2HY" failed: Permission denied (13)

I don't understand what's happening.

edit: I just found out that the destination folder didn't have the write access for the root group. How would I give 100% access to this rsync user ? If I change its uid to 0, rsync stop working.

Improve this question
6
  • Maybe there's a write lock on that particular file. I don't think you can open a file with a write lock on it for anything until that write lock is closed.
    – James T Snell
    Jun 23, 2011 at 18:18
  • If you want to run something with uid=0, just use the existing root account. Anything else will likely result in pain and confusion.
    – larsks
    Jun 23, 2011 at 18:47
  • Can't, I forbid the root login in my sshd config, only user + key.
    – Bastien974
    Jun 23, 2011 at 18:48
  • "I forbid the root login in my sshd config, only user + key" but you have another user with almost as much authority? How is that more secure?
    – EightBitTony
    Jun 23, 2011 at 19:31
  • If you change the uid of the rsync user to 0 then you are allowing root access. There is no difference; all permissions are granted based solely on the userid. We can't help you if you're lying to yourself. If you need rsync to have root level access, you need to run it as root. You can allow key-only root access and restrict the key usage to specific ip addresses, which should get you where you need to be.
    – larsks
    Jun 23, 2011 at 19:49

2 Answers 2

Reset to default
3

What you've done, usermod -G root -a rsync, is to add the rsync user to the root group. This has no effect whatsoever on most systems, because the root group is not special. There are systems where being in the root group is necessary to escalate privileges to the root user, but it is never sufficient (the root group is the group of users who may use sudo, or some equivalent setup).

In terms of security, giving a user the permission to write files anywhere is exactly equivalent to giving that user root powers. (The user can overwrite /bin/su, or /etc/passwd, or /usr/sbin/sshd, or any number of other programs and databases that would let her set up a backdoor for herself.)

If you need to access arbitrary files over ssh, allow ssh logins as root. Not with a password (or else a long, randomly generated one), just with a key (which you'll need to protect carefully, of course). In /etc/sshd_config, put

PermitRootLogin yes
Improve this answer
0

Another way of allowing arbitrary file access would be to grant your rsync user the appropriate permissions via POSIX ACLs on your filesystem(s). I wrote up a quick summary of inherited ACLs here.

If your requirement to allow the user to write to any file at all is accurate, then there may be bigger security concerns, and it may be more prudent to do as others suggest and just allow root logins - keeping the setup simple will save you time in future.

However I strongly suspect that you don't, in fact, require the ability to put files anywhere at all on the system. If that's the case, and you actually just need to be able to put them in some number of arbitrary places, then POSIX ACLs may help you out.

If you really do need to be able to overwrite, for example, /etc/passwd via this mechanism, then you should consider a different approach. If you're pushing out configuration changes including accounts, you'll have a better time of it if you use a configuration management system like puppet or cfengine. These will let you specify configuration changes which are then pushed out to the remote system.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .