remote logging non-daemon mode

Doug Lochart dlochart at gmail.com
Thu Dec 6 14:57:27 GMT 2007


On Dec 6, 2007 12:52 AM, Matt McCutchen <matt at mattmccutchen.net> wrote:

> On Wed, 2007-12-05 at 23:21 -0500, Doug Lochart wrote:
> > Now I am having another issue and that is passing a log format in the
> > rsync-path.  I can see it is coming over but for some reason a defauly
> > --log-format=%o is appended after --server is added by rsync.  This
> > effectively overrides the log-format I supplied.  How do I stop this
> > default log-format from being appended after --server?
>
> You want to use --log-file-format to control the server's log file.  A
> --log-format option passed to a server is a hint that helps the client
> perform its own logging properly.
>
thanks

>
> But seriously, you should use a properly configured rsync daemon.
> Making the client pass the log format in the --rsync-path and making the
> validation script check it is a hack to achieve centralized control of
> logging in a plain-server setup, while an rsync daemon is *designed* to
> give you this control;


I would love nothing more than to use the daemon approach.  It seemed like
the right thing to do in the first place especially after the investigation
(reading) I did this is why we went that approach to begin with.



> > On the protocol version error I have discovered the problem  I am
> > using a validation script as part of rthe ssh key to make sure that
> > only rsync is executed within that shell.
>
> if you stick with the plain server, you can expect more headaches like
> this one.
>

I can see how it could be problematic.


>
> > We used ssh to create a tunnel using a users ssh key.  With this
> > tunnel we were able to access any module defined in the system.
>
> > Each module needs to be protected from the others so if a user logs in
> > with their credentials they should not have access to any other
> > module.
>
> Of course.  I'm trying to understand your initial setup and how users
> could access each other's modules.  By a "tunnel", do you mean that you
> forwarded a background-listening daemon's port or that you invoked a
> single-use daemon over ssh?  I assume each user has his/her own ssh key?
> Are you using the rsync daemon's own authentication protocol ("auth
> users")?
>

The former.  Each client creates its own SSH tunnel via port forwarding.
The rsync client then sets the target to localhost and the local port of the
tunnel.  The remote end is port 873 of the rsync server machine with a
daemon running.  Each user has there own module.  I can post the
rsyncd.confif that would help.  One of our requirements is that the
backup process has
to be hands off (no user interaction whatsoever).

>
> Anyway, it's easy do a secure rsync daemon setup with ssh connections
> and authentication.  Make a separate daemon configuration file for each
> user listing only the modules he/she is allowed to access.  Then set
> each user's forced command to invoke a single-use daemon with the
> appropriate configuration file ("rsync --daemon --server
> --config=< rsyncd-user.conf> .").  The situation for multiple single-use
> daemons sharing a single log file is exactly the same as for multiple
> concurrent connections to a background daemon: lines of output get
> intermingled, but nothing terrible happens.
>
> You don't have to write a separate configuration file for each user
> manually.  You can force a script that generates a configuration file
> specific to the user from a global template and provides the file to the
> daemon on one of its fds.  A better alternative might be to enhance
> rsync with a --client-user=USER daemon option that makes the daemon
> assume the client is USER without performing its own authentication
> protocol.  Then all the forced commands could use a single configuration
> file but pass different --client-user options.
>
> Matt
>
This sounds interesting.  I guess I was too new to rsync when we started to
see that this type of thing could be done.  I still need to get my head all
the way around it and actually play with it but I get the gist and it looks
cool.  A few questions on your above comments.

1)  Is it ok to manually put in --server?  The rsync docs explicitly say not
to do it.
2)  In this approach I do NOT have a daemon running on the server correct?
It is just that each invocation starts an rsync server in daemon mode to
handle that client correct?
3)  In your above approach what would stop a clever person from hacking the
client script and changing the rsyncd.conf to match another clients?  The
basic daemon approach runs as root and then just applies uid/gid from the
module to files sent but does not run as that user.  When the daemon is run
by your approach is it running as the user and not root?  If so then unix
permissions would come into play and the security hole closed.

Thanks Matt !


-- 
What profits a man if he gains the whole world yet loses his soul?

-- 
What profits a man if he gains the whole world yet loses his soul?
-------------- next part --------------
HTML attachment scrubbed and removed


More information about the rsync mailing list