I'm not going to comment on your entire message, just pieces of it:
On Mon, Feb 12, 2001 at 12:53:39PM -0500, Wrieth, Henry wrote:
...
> -Authentication:
> If we are going to spawn the child as the client user, we need to be assured
> the user is who he or she claims to be. Currently, rsyncd uses a password
> file with arbitrary users (users not necessarily on the host) and a clear
> text password, or secrets file. It is secured by 'root read only'
> permissions. Modules may permission allowed users from that list. We all
> recognize that the secrets file is a good, but antique idea and does not
> pass audits any longer. My only recommendation is that we upgrade the login
> functionality to allow native OS usernames and passwords. Then perhaps, we
> extend this later to include LDAP, radius, kerberos, PKI, etc.
The reason why the password is in the clear in the secrets file is not an
antique idea: it avoids having to send the passwords in the clear over the
network, which you cannot avoid with native OS usernames and passords
unless you use encryption like SSH does. Having the password in the clear
on the server side enables using it as a key for a random number challenge-
response which rsync does behind the scenes.
> --execute
> Once we have child daemons securely spawning as normal users we can have no
> worries about adding an --execute option. I say this because we are not
> granting any new privileges to the user which they do not already have by
> logging onto the box directly. Jil can not do things as Jak, Like send
> nasty mail to his boss, and can not do things as root like, rm /.
Keep in mind that it's not just the user id authentication we're concerned
about, it's also the chroot environment. The chroot is a safeguard against
holes in the rsync server implementation and not one we're usually willing
to give up.
> -Summary
> I think --execute could become a safe and extremely powerful addition to
> rsync by making two relatively simple changes to the existing daemon.
>
> 1.) When 'uid=' is not specified in a module spawn the child as
> the client username
> 2.) Update the login function to allow native OS username and
> password. 'login=native'
>
> Now we can create an --execute feature to allow execution of arbitrary
> scripts either before or after file deployment and either 'on success' or
> 'on failure'.
> --execute="/path/doit -q arg" after_deploy on_success
>
> Perhaps it be required that if the --execute option is used then either the
> uid= or login= be enforced. That is I don't think --execute should be
> allowed in anonymous mode.
Serious suggestion: from what I understand about your application now, it
seems to me that using '-e ssh' would be the best way for you to go instead
of an rsync daemon. Is there a reason why that's not an option for you?
- Dave Dykstra
