Enhanced authentication and authorization in rsyncd

[Wayne Davison]

So, I've tweaked your patch, and you'll find the results in the git
version of rsync and (currently) in a patch.  Here are some details:

> 1. allow the uid and gid used to access a certain module to be
> determined by the authenticated user -
>     uid = __auth__ will use the auth_user's uid
>     gid = __auth__ will use the auth user's main group's gid

I changed this to use a new environment-variable expanding idiom in
the config file.  So, the above would be written like this:

    uid = %RSYNC_USER_NAME%
    gid = *

The "*" setting was an already-implemented feature in the git repo which
expands into the uid user's groups.

> 2. seteuid and not just setuid

Applied.

> 3. added "rw users" to allow read/write access to a module, "ro users"
> to allow read only access to a module and "deny users".  "read only"
> on the module overrides the user's authorization.
>
> 4. added support for groups - with a '@' prefix. For instance: "auth
> users = tridge, susan, @rsync_users"

I changed this to keep a single "auth users" setting, but did not commit
it to git (at least, not yet).  I created a patch named group-auth.diff,
which you can find here:

    http://gitweb.samba.org/?p=rsync-patches.git;a=tree

These patches apply to the current git-repo version of rsync.

In the group-auth patch you'll find your @group idiom for specifying a
group name (as in your patch, if the username is a real user, that
real-user's groups are compared against the @group items).  I changed
your ro, rw, and deny settings to be specified via suffixes.  For
example:

    auth user = joe:deny admin:rw @rsync:ro susan

This makes the logic very easy to figure out, since we just match each
item in order and go with the first match.  That makes the deny suffix's
job to override an authorization that would succeed in a later match.
In my patch, the module's "read only" setting is the default, and the
ro/rw suffix of the first matching rule overrides that value.  I also
added the ability to put a @group password in the secrets file, so if
you define "@rsync:secret", that lets anyone in the rsync group login
with that password (a group-matching rule looks for either a user
password or a group password, while a user-matching rule only looks
for a user password).

Potential backward incompatibility:  usernames used to be able to start
with a @ and (surprisingly, given the syntax of the secrets file) even
contain a colon.

If anyone likes/dislikes this, please feel free to comment.

..wayne..