[scponly] enabling an rsync daemon on top of scponly setup...

[Kaleb Pederson]

A full read through the rsync manual would probably be instructive and helpful 
in answering your questions.

The following forms of client invocation will use the rsync daemon:

rsync [OPTION]... SRC [SRC]... [USER@]HOST::DEST
rsync [OPTION]... SRC [SRC]... rsync://[USER@]HOST[:PORT]/DEST
rsync [OPTION]... [USER@]HOST::SRC [DEST]
rsync [OPTION]... rsync://[USER@]HOST[:PORT]/SRC [DEST]

Any time the '::' or 'rsync://' is used, the rsync daemon will be invoked.  So 
the quick answer is that as long as your users type the correct form, they 
will not be breaking out of the chroot.

Also, when you setup the rsync daemon, you have to give it a set of paths that 
can be accessed, so it would in no way allow them to break out of the chroot, 
it just gives them access to specific portions of a filesystem tree.

I hope that helps.

--Kaleb


On Monday 14 May 2007, Gore Jarold wrote:
> --- Gore Jarold <gore_jarold at yahoo.com> wrote:
> > This is a theory question, and more to do with rsync
> > in general than scponly, but I'd really like this
> > groups take on it...
> >
> > I run an scponly-enabled system that is primarily a
> > target for users to run rsync over SSH.  All users
> > use
> > the chrooted scponlyc shell.  I do not currently run
> > an rsync daemon.
> >
> > All is well, everyone is happy.
> >
> > What happens if I just fire up an rsync daemon ?
> >
> > My thoughts are, most modern rsync client
> > implementations _default_ to '-e SSH' mode, and any
> > clients that didn't are already configured to run
> > with
> > '-e ssh', so nobody will suddenly find themselves
> > unintentionally running over rsync instead of ssh,
> > right ?
> >
> > Will this even be possible, since their shell
> > (scponlyc) restricts them to scp/ssh commands ?
> >
> > If they do successfully connect, I assume they will
> > authenticate against the base systems' /etc/passwd
> > and
> > ... will they be chrooted as defined in their home
> > directory in /etc/passwd ?  Does anything in there
> > matter at all besides uid/password ?
>
> Nobody has any comments on this ?
>
> I think what will happen is that rsyncd connections
> will happen outside the bounds of my scponlyc setup,
> and that using rsyncd, remote users will have full run
> of my filesystem ... which isn't bad, as long as
> permissions are done right ... but it isn't nearly as
> locked down as my scponlyc setup.
>
> For instance, a remote rsyncd user could write files
> to the systems base /tmp, or could read files in
> /usr/lib or something like that.  Again, not terrible,
> but I'd like to avoid it.
>
> Is there something for rsyncd that is similar to the
> /etc/ftpchroot facility, wherein every user has a line
> that designates a chroot for their use of the ftp
> daemon ?
>
> Is anyone here using rsyncd in conjunction with
> scponlyc ?
>
>
>
> ___________________________________________________________________________
>_________ We won't tell. Get more on shows you hate to love
> (and love to hate): Yahoo! TV's Guilty Pleasures list.
> http://tv.yahoo.com/collections/265
>
> _______________________________________________
> scponly mailing list
> scponly at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/scponly


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : https://lists.ccs.neu.edu/pipermail/scponly/attachments/20070514/139e7fb6/attachment.bin