> $ rsync -e 'ssh -v' lingnu.com: > OpenSSH_5.1p1 Debian-2, OpenSSL 0.9.8g 19 Oct 2007 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug1: Connecting to lingnu.com [199.203.56.105] port 22. > debug1: Connection established....> debug1: Sending command: rsync --server --sender -de.L .As we can see, rsync runs ssh, and tells it to run, on the other side, rsync with the "-e" flag. I am not really sure what and how the "." and "L" are parsed by rsync (part of my problem). The reason this is brought up is because I'm using rssh (http://www.pizzashack.org/rssh/) as the user's shell to limit that user to only be allowed to run rsync. Rssh, however, prevent the passing of the "-e" option to rsync, as it claims (with some amount of justification) that this option allows someone to cause rsync to run any command at all, escaping the limitations imposed by rssh. So my questions: 1. Why does rsync need to pass "-e" to the remote side? After all, the connection is already established at that point. 2. What does this -e mean? What causes the remote side to really not run anything (trying to run ".L" from the path would be the way I would interpret the command at that point - obviously rsync disagrees :-) Thanks, Shachar
So, I've done some RTFS, and this is what I've got. I'd still love it if Wayne could confirm that my understanding of the source is correct. Shachar Shemesh wrote:> So my questions: > 1. Why does rsync need to pass "-e" to the remote side? After all, the > connection is already established at that point.-e when combined with --server means something different than it does normally. With --server it is a means for the client to hand over to the server the options and command lines it received itself (hard links, symbolic link processing etc.) as well as the protocol version used.> 2. What does this -e mean? What causes the remote side to really not > run anything (trying to run ".L" from the path would be the way I > would interpret the command at that point - obviously rsync disagrees :-)The "." means protocol 3.0 (with explicit numbers for other numbers. i.e. - protocol version 3.1 will be listed as "3.1". The current code says protocol 4.0 will also be listed as ".", but I'm fairly sure that's just a bug that has not manifested yet). The L means LUTIMES support. The thing I would like Wayne to confirm is that if the --server option is given, the "-e" option will never cause an application to be run, and should thus not be considered dangerous. Thanks, Shachar
On Sun, Oct 05, 2008 at 06:47:47AM +0200, Shachar Shemesh wrote:> Rssh, however, prevent the passing of the "-e" option to rsync, as it > claims (with some amount of justification) that this option allows > someone to cause rsync to run any command at all, escaping the > limitations imposed by rssh.As has been mentioned on the list before, this is not the right check. A restricted shell should instead check that "--server" was specified (and it is fine to check that it is the first option on the line too), at which point checking for -e is immaterial (since it never runs anything on the server side). The use of -e conveys some flags in a way that is compatible with older versions (which used to ignore -e when combined with --server) and does not slow down the start of a transfer (which would otherwise need to wait for the initial protocol exchange before deciding if they could send sub-flags, thus slowing down the handshake by at least a round- trip). ..wayne..
On Sun, Oct 05, 2008 at 06:47:47AM +0200, Shachar Shemesh wrote:> The reason this is brought up is because I'm using rssh > (http://www.pizzashack.org/rssh/) as the user's shell to limit that > user to only be allowed to run rsync.I looked at the source, and created a patch to make it just require the --server option as the first option. While I was looking at the code, I noticed that the check_command() function was busted in that it would accept any abbreviated path of a command (e.g. "/usr/bin/rs" would match "/usr/bin/rsync"). The author apparently didn't know that strncmp() stops at a null (unlike memcmp()), so the length-trimming that is done can just be removed. My patch fixes that too. ..wayne.. -------------- next part -------------- A non-text attachment was scrubbed... Name: rssh.diff Type: text/x-diff Size: 1294 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20081005/766efaaf/rssh.bin
> Personally, and this is not something that any shell can solve, I > would love for a way to limit the files that the --server side rsync > allows access to.I have an ssh command wrapper script, which I believe (and now just hope) limits the access an SSH key provides to a user who uses this key to authenticate to a system so they are only able to perform restricted rsync operations. Let me do some further testing with this and I will get back to you with the code, once I have looked at it again. In the meant time if you would like to see the code before I look though it and post it to this list, then you are welcome to download the latest version of PrinterSetup from the following URL : PrinterSetup : http://www.lucidsystems.org/printingworks/printersetup Once downloaded have a look in the following directories : - ExampleFiles/Deployment/PrinterSetup_OSX_SYNC - ExampleFiles/Deployment/PrinterSetup_OSX_UPDATE The idea behind the SYNC and UPDATE systems is that you may have some files (in this case printers configuration information) on a server and that you may want to restrict read and write access to only this information which a particular SSH key will allow. I am about to setup a server to start testing the robustness this kind of SSH key restriction system, so the timing of your email is great! If these scripts are not sufficiently locking down the read and write access to a particular path then I am interested to help in any way to make this kind of restriction possible. If you have a moment, this system may solve your issue. However, if you see a flaw in the way it works I would be most grateful if you would kindly let me know. I do think that there must be a better way than using SSH keys to restrict access. However, if you are looking for an immediate solution then this may be an option, provided it actually works. Thanks. On 8/10/2008, at 4:59 AM, Rami Addady wrote:> Hello Shachar, > > You can use rrsync instead: > http://samba.anu.edu.au/ftp/unpacked/rsync/support/rrsync > > > Regards, > Rami Addady > http://www.active.co.il > > > > Shachar Shemesh wrote: > > Wayne Davison wrote: > >> On Sun, Oct 05, 2008 at 06:47:47AM +0200, Shachar Shemesh wrote: > >> > >>> The reason this is brought up is because I'm using rssh > >>> (http://www.pizzashack.org/rssh/) as the user's shell to limit > that > >>> user to only be allowed to run rsync. > >>> > >> > >> I looked at the source, and created a patch to make it just > require the > >> --server option as the first option. > >> > >> While I was looking at the code, I noticed that the check_command() > >> function was busted in that it would accept any abbreviated path > of a > >> command (e.g. "/usr/bin/rs" would match "/usr/bin/rsync"). The > author > >> apparently didn't know that strncmp() stops at a null (unlike > memcmp()), > >> so the length-trimming that is done can just be removed. My > patch fixes > >> that too. > >> > > Last I talked to the rssh maintainer (about a couple of years ago) I > > was so frustrated with the attitude that I decided to only use rssh > > until I knock something better together myself. He (used to) care > > about scp and sftp, and little else. You can send the patch over, if > > you're feeling lucky. I doubt I'll bother. The only reason I brought > > the question up was that if I am going to be writing something > myself, > > I would need to know what to make it enforce. > > > > Personally, and this is not something that any shell can solve, I > > would love for a way to limit the files that the --server side rsync > > allows access to. I can then use a custom shell to pass that command > > line to rsync to ensure it's enforced. > >> ..wayne.. > >> > > > > Shachar > -- > Please use reply-all for most replies to avoid omitting the mailing > list. > To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync > Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html