rsync // su

jw schultz jw at
Fri Sep 5 13:52:25 EST 2003

On Thu, Sep 04, 2003 at 11:36:31PM -0400, Carson Gaspar wrote:
> --On Friday, September 05, 2003 12:45 PM +1000 Martin Pool 
> <mbp at> wrote:
> >On  4 Sep 2003 Atom 'Smasher' <atom at> wrote:
> >
> >>obviously, allowing root logins through ssh (or any protocol, really)
> >>is best avoided.
> >
> >Can you explain why you hold that opinion?
> Speaking as a security weenie, the problem is the utter lack of an audit 
> trail. "root" isn't a person, it's a role. If you allow direct role logins, 
> you have no idea what person is responsible.
> I don't, however, think that the rsync protocol is the right place to fix 
> it(speaking about normal rsync +rsh/ssh/whatever, not the rsync daemon). 
> Fixing the security issues with the daemon is a much more difficult 
> proposition.
> Possible options:
> - Don't allow root to log in, require su, sudo, or a similar mechanism 
> (such as RBAC in Solaris). This makes rsync unhappy.
> - Create multiple UID 0 accounts, one per person. Works, but not the most 
> manageable of solutions.
> - Only allow root logins from cryptographically authenticated trusted 
> hosts. This assumes you can trust the audit logs of host A to figure out 
> who logged in to host B. Current SSH implementations are less than stellar 
> about this, but the protocol does allow it.
> - Allow cryptographically authenticated remote users (such as kerberos 
> roles - user.admin at dom.ain) to log in as role accounts. Sadly, I don't know 
> of anything but kerberos that really does this well. SSH can do something 
> similar using RSA/DSA auth and logging the key fingerprint.
> - Allow role based logins based on user credentials (via PAM/NSS, or other 
> mechanisms). I'd log into the remote host as root, be authenticated as 
> carson, but logged in as root. The usual way to shoehorn this in is to 
> overload the username (e.g. log in as the user root/carson).

Rsync is pretty agnostic about how the connection is
established.  If ssh doesn't support a security mechanism
you find sufficient you need merely to create a utility that
provides that subset of rsh/ssh functionality required by

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at

		Remember Cernan and Schmitt

More information about the rsync mailing list