Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
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. –  Doc Jun 23 '11 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 '11 at 18:47
    
Can't, I forbid the root login in my sshd config, only user + key. –  Bastien974 Jun 23 '11 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 '11 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 '11 at 19:49

2 Answers 2

up vote 3 down vote accepted

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
share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.