From bescoto@stanford.edu Tue Nov 6 07:14:22 2001 From: bescoto@stanford.edu (Ben Escoto) Date: Mon, 05 Nov 2001 23:14:22 -0800 Subject: [Rdiff-backup] Testing Message-ID: <200111060714.fA67EMx02372@folly.stanford.edu> aoeutsoenut From bescoto@stanford.edu Tue Nov 6 07:24:44 2001 From: bescoto@stanford.edu (Ben Escoto) Date: Mon, 05 Nov 2001 23:24:44 -0800 Subject: aoeusaonetu Message-ID: <200111060724.fA67Oi102461@folly.stanford.edu> Testing... From bescoto@stanford.edu Sat Nov 10 02:02:32 2001 From: bescoto@stanford.edu (Ben Escoto) Date: Fri, 09 Nov 2001 18:02:32 -0800 Subject: v0.4.1 released Message-ID: <200111100202.fAA22Wh31895@folly.stanford.edu> I just put v0.4.1 on the web page. Since a couple of users has asked about this, rdiff-backup now supports host::filename syntax with any combination of remote and local paths, as in: rdiff-backup bill@host1.net::source_file jones@host2.net::target Also 0.4.1 has numerous bugfixes over 0.4.0. -- Ben Escoto From mike@nux.co.uk Tue Nov 20 00:23:16 2001 From: mike@nux.co.uk (mike wolman) Date: Tue, 20 Nov 2001 00:23:16 +0000 (GMT) Subject: secure remote backups Message-ID: Hi, Is it possible to use rdiff to first log in to a machine as a normal user then su before performing the backup thus preventing root from sshing into the remote machine directly? Mike. From bescoto@stanford.edu Tue Nov 20 00:25:09 2001 From: bescoto@stanford.edu (Ben Escoto) Date: Mon, 19 Nov 2001 16:25:09 -0800 Subject: secure remote backups In-Reply-To: Your message of "Tue, 20 Nov 2001 00:23:16 GMT." Message-ID: <200111200025.fAK0P9W05217@folly.stanford.edu> --==_Exmh_2040069169P Content-Type: text/plain; charset=us-ascii >>>>> "MW" == mike wolman >>>>> wrote the following on Tue, 20 Nov 2001 00:23:16 +0000 (GMT) MW> Hi, Is it possible to use rdiff to first log in to a machine as MW> a normal user then su before performing the backup thus MW> preventing root from sshing into the remote machine directly? Yes, kind of, but this won't eliminate the security risks, so the primary purpose would probably be to run it on a machine not allowing root ssh connections. rdiff-backup usually opens a connection to a remote host by executing "ssh user@host rdiff-backup --server", but you can control this using the --remote-schema option. Instead of running rdiff-backup directory on the remote side, you could instead run a script that was either suid, or ran su itself, and then ran rdiff-backup. For instance: rdiff-backup --remote-schema "ssh %s su root -c 'rdiff-backup --server'" foo user@remote.host::bar Will log into remote.host as user, but then ssh will immediately use su to run 'rdiff-backup --server' as root. (Assuming I didn't mess up the quoting.) The problem for security is that however you log into the remote machine, the rdiff-backup server is running as root (assuming you want to preserve file ownership), so a malicious user on the local machine could tell the server to do bad things. -- Ben Escoto --==_Exmh_2040069169P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Exmh version 2.2 06/23/2000 iD8DBQE7+aLT+owuOvknOnURAomXAKCMFtvBz5gJNqYg6Q+st3KgfsrLUACfbg/6 cfAzFyZSgDH171+alxJX33Q= =IwOy -----END PGP SIGNATURE----- --==_Exmh_2040069169P-- From bescoto@stanford.edu Tue Nov 20 00:30:13 2001 From: bescoto@stanford.edu (Ben Escoto) Date: Mon, 19 Nov 2001 16:30:13 -0800 Subject: v0.4.2 released Message-ID: <200111200030.fAK0UDh05261@folly.stanford.edu> --==_Exmh_2040625834P Content-Type: text/plain; charset=us-ascii Oh, almost forgot, I put v0.4.2 on the web page. The main change is that I plugged a memory leak (I guess automatic garbage collection doesn't save you from those..). I only noticed because I was running top and my rdiff-backup process had grown to 140MB! Here is the the changelog entry: New in v0.4.2 (2001/11/19) -------------------------- Significant speed increases (maybe 20% for local sessions) when dealing with directories that do not need to be updated much. Fixed memory leak. rdiff-backup should now run in almost constant memory (about 6MB on my system). Enabled buffering of object transfers, so remote sessions can be 50-100%+ faster. rdiff-backup now thinks it is running as root if the destination connection is root. Thus rdiff-backup will preserve ownership even if it is not running as root on the source end. If you abort rdiff-backup or it fails for some reason, it is now more robust about recovering the next time it is run (before it could fail in ways which made subsequent sessions fail also). However, it is still not a good idea to abort, as individual files could be in the process of being written and could get corrupted. If rdiff-backup encounters an unreadable file (or, if --change-source-perms is given, a file whose permissions it cannot change), it will log a warning, ignore the file, and continue, instead of exiting with an error. -- Ben Escoto --==_Exmh_2040625834P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Exmh version 2.2 06/23/2000 iD8DBQE7+aQO+owuOvknOnURAtx6AJ0SKmPhPS2687uyxoUNjFQ35pJEyACcCPkU 2M2iuXuljNiXIrffMwM7z2U= =c/I3 -----END PGP SIGNATURE----- --==_Exmh_2040625834P-- From mike@nux.co.uk Wed Nov 21 14:41:15 2001 From: mike@nux.co.uk (mike wolman) Date: Wed, 21 Nov 2001 14:41:15 +0000 (GMT) Subject: secure remote backups In-Reply-To: <200111200025.fAK0P9W05217@folly.stanford.edu> Message-ID: Hi Ben, I have tried your suggestion however when i try to ssh and su i get the following problem from su: standard in must be a tty I have had a hunt for anybody else trying to run su from ssh but have not found a solution. Thanks again for your suggestion, Mike. On Mon, 19 Nov 2001, Ben Escoto wrote: > >>>>> "MW" == mike wolman > >>>>> wrote the following on Tue, 20 Nov 2001 00:23:16 +0000 (GMT) > > MW> Hi, Is it possible to use rdiff to first log in to a machine as > MW> a normal user then su before performing the backup thus > MW> preventing root from sshing into the remote machine directly? > > Yes, kind of, but this won't eliminate the security risks, so the > primary purpose would probably be to run it on a machine not allowing > root ssh connections. > > rdiff-backup usually opens a connection to a remote host by > executing "ssh user@host rdiff-backup --server", but you can control > this using the --remote-schema option. Instead of running > rdiff-backup directory on the remote side, you could instead run a > script that was either suid, or ran su itself, and then ran > rdiff-backup. > > For instance: > > rdiff-backup --remote-schema "ssh %s su root -c 'rdiff-backup > --server'" foo user@remote.host::bar > > Will log into remote.host as user, but then ssh will immediately use > su to run 'rdiff-backup --server' as root. (Assuming I didn't mess up > the quoting.) > > The problem for security is that however you log into the remote > machine, the rdiff-backup server is running as root (assuming you want > to preserve file ownership), so a malicious user on the local machine > could tell the server to do bad things. > > > -- > Ben Escoto > > From bescoto@stanford.edu Wed Nov 21 21:26:13 2001 From: bescoto@stanford.edu (Ben Escoto) Date: Wed, 21 Nov 2001 13:26:13 -0800 Subject: secure remote backups In-Reply-To: Your message of "Wed, 21 Nov 2001 14:41:15 GMT." Message-ID: <200111212126.fALLQDT02474@folly.stanford.edu> --==_Exmh_-511287360P Content-Type: text/plain; charset=us-ascii >>>>> "MW" == mike wolman >>>>> wrote the following on Wed, 21 Nov 2001 14:41:15 +0000 (GMT) MW> Hi Ben, I have tried your suggestion however when i try to ssh MW> and su i get the following problem from su: standard in must be MW> a tty MW> I have had a hunt for anybody else trying to run su from ssh but MW> have not found a solution. Hmm, I think something like the ssh-then-su method still could work, but you would need some more complicated wrapper... Ok, how about these suggestions instead: 1. Suid script that runs rdiff-backup --server. I think you would have to create another user id, and make sure only that user has access to the script. 2. Instead of running rdiff-backup on machine A and trying to get it to log in to machine B which doesn't accept ssh root logins, run rdiff-backup on machine B (after you 'su' normally) with machine A being remote. 3. Reconfigure ssh on the remote machine to accept root logins. To do this, make sure the line PermitRootLogin yes appears in your sshd configuration file, usually at /etc/ssh/sshd_config. Anything here look promising? -- Ben Escoto --==_Exmh_-511287360P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Exmh version 2.2 06/23/2000 iD8DBQE7/Bvy+owuOvknOnURAmLAAJ9z4NiGCuapr21C38DmfMPsTR9fDgCeIP/f ZPS7ikKRNZTFR9L5ARoh0ls= =ABsm -----END PGP SIGNATURE----- --==_Exmh_-511287360P-- From mike@nux.co.uk Thu Nov 22 12:33:12 2001 From: mike@nux.co.uk (mike wolman) Date: Thu, 22 Nov 2001 12:33:12 +0000 (GMT) Subject: secure remote backups In-Reply-To: <200111212126.fALLQDT02474@folly.stanford.edu> Message-ID: Hi Ben, I will give your suggestions a try, I am not too keen on opening up root ssh access on the remote machines but i will give your other suggestions a try. Thanks, Mike. On Wed, 21 Nov 2001, Ben Escoto wrote: > >>>>> "MW" == mike wolman > >>>>> wrote the following on Wed, 21 Nov 2001 14:41:15 +0000 (GMT) > > MW> Hi Ben, I have tried your suggestion however when i try to ssh > MW> and su i get the following problem from su: standard in must be > MW> a tty > > MW> I have had a hunt for anybody else trying to run su from ssh but > MW> have not found a solution. > > Hmm, I think something like the ssh-then-su method still could work, > but you would need some more complicated wrapper... Ok, how about > these suggestions instead: > > 1. Suid script that runs rdiff-backup --server. I think you would > have to create another user id, and make sure only that user has > access to the script. > > 2. Instead of running rdiff-backup on machine A and trying to get it > to log in to machine B which doesn't accept ssh root logins, run > rdiff-backup on machine B (after you 'su' normally) with machine A > being remote. > > 3. Reconfigure ssh on the remote machine to accept root logins. To > do this, make sure the line > > PermitRootLogin yes > > appears in your sshd configuration file, usually at > /etc/ssh/sshd_config. > > Anything here look promising? > > > -- > Ben Escoto > From fabio@unesp.br Fri Nov 23 11:49:27 2001 From: fabio@unesp.br (Fabio de Oliveira) Date: Fri, 23 Nov 2001 09:49:27 -0200 (BRST) Subject: Please, help me. Message-ID: Hi, everyone. I hope that you forgive my english. When I run the rdiff-backup, I get this: xxxxx@xxx:~./rdiff-backup foo/usr /bar File "./rdiff-backup", line 138 if predicate(i): yield i ^ SyntaxError: invalid syntax Can anybody help me? Thank you a lot!! --------------------------------------------------------------------------- Fabio de Oliveira Analista de Redes - GRC Assessoria de Informatica - UNESP From bescoto@stanford.edu Fri Nov 23 12:15:09 2001 From: bescoto@stanford.edu (Ben Escoto) Date: Fri, 23 Nov 2001 04:15:09 -0800 Subject: Please, help me. In-Reply-To: Your message of "Fri, 23 Nov 2001 09:49:27 -0200." Message-ID: <200111231215.fANCF9d01795@folly.stanford.edu> --==_Exmh_1405375999P Content-Type: text/plain; charset=us-ascii >>>>> "FdO" == Fabio de Oliveira >>>>> wrote the following on Fri, 23 Nov 2001 09:49:27 -0200 (BRST) FdO> When I run the rdiff-backup, I get this: FdO> File "./rdiff-backup", line 138 if predicate(i): yield i ^ FdO> SyntaxError: invalid syntax Hi, you probably don't have python2.2 installed. Try typing in 'python' at your shell prompt. If it says Python 2.2b1 (#1, Oct 31 2001, 21:28:04) or similar then you are fine. If it says Python 1.52 or anything earlier than v2.2, then you have to install the new version of python to use rdiff-backup. -- Ben Escoto --==_Exmh_1405375999P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Exmh version 2.2 06/23/2000 iD8DBQE7/j3G+owuOvknOnURAtU5AKCPcDZcFuBDPpT88pMlHpsMMUPB0wCeL8Af 2kZikMYjdcH7qS246ZyS7TM= =rtpm -----END PGP SIGNATURE----- --==_Exmh_1405375999P-- From Jason_Piterak@c-i-s.com Tue Nov 27 16:14:11 2001 From: Jason_Piterak@c-i-s.com (Jason Piterak) Date: Tue, 27 Nov 2001 11:14:11 -0500 Subject: secure remote backups Message-ID: Ben, Haven't had a chance to dig into rdiff-backup lately, been too busy with other things. But, I tried your idea of negative --exclude regex parameters to do positive matches (eg: backup all archive files) and couldn't get it to work... Here's what I tried (regex courtesy of our local Perl guru): --exclude '^(.*?\.(?!(tar|rpm|tgz|gz|z|bz2|Z)).*?|[^\.]*?)$' Looking in the normal Python places I noticed that python has issues with '\' characters in regex matching, especially when used as a quoted string in the code: ------------------------------------------- Regular expressions use the backslash character ("\") to indicate special forms or to allow special characters to be used without invoking their special meaning. This collides with Python's usage of the same character for the same purpose in string literals; for example, to match a literal backslash, one might have to write '\\\\' as the pattern string, because the regular expression must be "\\", and each backslash must be expressed as "\\" inside a regular Python string literal. The solution is to use Python's raw string notation for regular expression patterns; backslashes are not handled in any special way in a string literal prefixed with "r". So r"\n" is a two-character string containing "\" and "n", while "\n" is a one-character string containing a newline. Usually patterns will be expressed in Python code using this raw string notation. ------------------------------------------- ... So, after looking at your regex call, and seeing that there was no 'r' prefixing the string, I tried doing the \\ \\\\ substitutions, and still got nowhere... Any ideas? Again, thanks for the trouble! --Jason --- Jason Piterak System Architect CIS Technical Services 33 Main St., Suite 302 Nashua, NH 03064 (603) 889-4684 - FAX (603) 889-0534 From Jason_Piterak@c-i-s.com Tue Nov 27 16:19:31 2001 From: Jason_Piterak@c-i-s.com (Jason Piterak) Date: Tue, 27 Nov 2001 11:19:31 -0500 Subject: secure remote backups Message-ID: Ben & Mike, Probably WAY overkill depending on your needs, but... what about running the rdiff-backup under user-mode linux with root ssh allowed to the virtual host? That way, if rdiff-backup (or sshd) is compromised, the cracker only gets to the virtual host... It also allows you to run several completely separate instances of rdiff-backup (with different chrooted environments and data repositories). Of course in order to do this, you'd either have to have some IP addresses available (one per VM), or you'd have to do some funky port forwarding on the host machine. Mike, please let us know what you _do_ end up with or get to work... Take care, --Jason --- Jason Piterak System Architect CIS Technical Services 33 Main St., Suite 302 Nashua, NH 03064 (603) 889-4684 - FAX (603) 889-0534 > -----Original Message----- > From: rdiff-backup-admin@keywest.Stanford.EDU > [mailto:rdiff-backup-admin@keywest.Stanford.EDU]On Behalf Of > mike wolman > Sent: Thursday, November 22, 2001 7:33 AM > To: Ben Escoto > Cc: rdiff-backup@keywest.Stanford.EDU > Subject: Re: secure remote backups > > > Hi Ben, > > I will give your suggestions a try, I am not too keen on > opening up root ssh access on the remote machines but i will > give your other suggestions a try. > > Thanks, > > Mike. > > On Wed, 21 Nov 2001, Ben Escoto wrote: > > > >>>>> "MW" == mike wolman > > >>>>> wrote the following on Wed, 21 Nov 2001 14:41:15 +0000 (GMT) > > > > MW> Hi Ben, I have tried your suggestion however when i try to ssh > > MW> and su i get the following problem from su: standard > in must be > > MW> a tty > > > > MW> I have had a hunt for anybody else trying to run su > from ssh but > > MW> have not found a solution. > > > > Hmm, I think something like the ssh-then-su method still could work, > > but you would need some more complicated wrapper... Ok, how about > > these suggestions instead: > > > > 1. Suid script that runs rdiff-backup --server. I think you would > > have to create another user id, and make sure only that user has > > access to the script. > > > > 2. Instead of running rdiff-backup on machine A and trying > to get it > > to log in to machine B which doesn't accept ssh root logins, run > > rdiff-backup on machine B (after you 'su' normally) > with machine A > > being remote. > > > > 3. Reconfigure ssh on the remote machine to accept root logins. To > > do this, make sure the line > > > > PermitRootLogin yes > > > > appears in your sshd configuration file, usually at > > /etc/ssh/sshd_config. > > > > Anything here look promising? > > > > > > -- > > Ben Escoto > > > > _______________________________________________ > Rdiff-backup mailing list > Rdiff-backup@keywest.Stanford.EDU > http://keywest.Stanford.EDU/mailman/listinfo/rdiff-backup > --- Jason Piterak System Architect CIS Technical Services 33 Main St., Suite 302 Nashua, NH 03064 (603) 889-4684 - FAX (603) 889-0534 > -----Original Message----- > From: rdiff-backup-admin@keywest.Stanford.EDU > [mailto:rdiff-backup-admin@keywest.Stanford.EDU]On Behalf Of > mike wolman > Sent: Thursday, November 22, 2001 7:33 AM > To: Ben Escoto > Cc: rdiff-backup@keywest.Stanford.EDU > Subject: Re: secure remote backups > > > Hi Ben, > > I will give your suggestions a try, I am not too keen on > opening up root ssh access on the remote machines but i will > give your other suggestions a try. > > Thanks, > > Mike. > > On Wed, 21 Nov 2001, Ben Escoto wrote: > > > >>>>> "MW" == mike wolman > > >>>>> wrote the following on Wed, 21 Nov 2001 14:41:15 +0000 (GMT) > > > > MW> Hi Ben, I have tried your suggestion however when i try to ssh > > MW> and su i get the following problem from su: standard > in must be > > MW> a tty > > > > MW> I have had a hunt for anybody else trying to run su > from ssh but > > MW> have not found a solution. > > > > Hmm, I think something like the ssh-then-su method still could work, > > but you would need some more complicated wrapper... Ok, how about > > these suggestions instead: > > > > 1. Suid script that runs rdiff-backup --server. I think you would > > have to create another user id, and make sure only that user has > > access to the script. > > > > 2. Instead of running rdiff-backup on machine A and trying > to get it > > to log in to machine B which doesn't accept ssh root logins, run > > rdiff-backup on machine B (after you 'su' normally) > with machine A > > being remote. > > > > 3. Reconfigure ssh on the remote machine to accept root logins. To > > do this, make sure the line > > > > PermitRootLogin yes > > > > appears in your sshd configuration file, usually at > > /etc/ssh/sshd_config. > > > > Anything here look promising? > > > > > > -- > > Ben Escoto > > > > _______________________________________________ > Rdiff-backup mailing list > Rdiff-backup@keywest.Stanford.EDU > http://keywest.Stanford.EDU/mailman/listinfo/rdiff-backup > From mike@nux.co.uk Tue Nov 27 17:35:42 2001 From: mike@nux.co.uk (mike wolman) Date: Tue, 27 Nov 2001 17:35:42 +0000 (GMT) Subject: secure remote backups In-Reply-To: Message-ID: Hi Jason, I am playing with a suid wrapper for rdiff, then sshing in as a backup user and running the wrapper script, as linux refuses to run scripts as suid, i am playing doing it with very limited c knowledge, and with a pile of other stuff mounting in the inbox i have not had a chance to get it setup. I will let you know as soon as i actually have it running. And yes usermode linux or a vm would be way overkill. Cheers, Mike. On Tue, 27 Nov 2001, Jason Piterak wrote: > Ben & Mike, > Probably WAY overkill depending on your needs, but... what about running > the rdiff-backup under user-mode linux with root ssh allowed to the virtual > host? That way, if rdiff-backup (or sshd) is compromised, the cracker only > gets to the virtual host... It also allows you to run several completely > separate instances of rdiff-backup (with different chrooted environments and > data repositories). > Of course in order to do this, you'd either have to have some IP addresses > available (one per VM), or you'd have to do some funky port forwarding on > the host machine. > > Mike, please let us know what you _do_ end up with or get to work... > > Take care, > > --Jason > > --- > Jason Piterak > System Architect > CIS Technical Services > 33 Main St., Suite 302 > Nashua, NH 03064 > (603) 889-4684 - FAX (603) 889-0534 > > > > > -----Original Message----- > > From: rdiff-backup-admin@keywest.Stanford.EDU > > [mailto:rdiff-backup-admin@keywest.Stanford.EDU]On Behalf Of > > mike wolman > > Sent: Thursday, November 22, 2001 7:33 AM > > To: Ben Escoto > > Cc: rdiff-backup@keywest.Stanford.EDU > > Subject: Re: secure remote backups > > > > > > Hi Ben, > > > > I will give your suggestions a try, I am not too keen on > > opening up root ssh access on the remote machines but i will > > give your other suggestions a try. > > > > Thanks, > > > > Mike. > > > > On Wed, 21 Nov 2001, Ben Escoto wrote: > > > > > >>>>> "MW" == mike wolman > > > >>>>> wrote the following on Wed, 21 Nov 2001 14:41:15 +0000 (GMT) > > > > > > MW> Hi Ben, I have tried your suggestion however when i try to ssh > > > MW> and su i get the following problem from su: standard > > in must be > > > MW> a tty > > > > > > MW> I have had a hunt for anybody else trying to run su > > from ssh but > > > MW> have not found a solution. > > > > > > Hmm, I think something like the ssh-then-su method still could work, > > > but you would need some more complicated wrapper... Ok, how about > > > these suggestions instead: > > > > > > 1. Suid script that runs rdiff-backup --server. I think you would > > > have to create another user id, and make sure only that user has > > > access to the script. > > > > > > 2. Instead of running rdiff-backup on machine A and trying > > to get it > > > to log in to machine B which doesn't accept ssh root logins, run > > > rdiff-backup on machine B (after you 'su' normally) > > with machine A > > > being remote. > > > > > > 3. Reconfigure ssh on the remote machine to accept root logins. To > > > do this, make sure the line > > > > > > PermitRootLogin yes > > > > > > appears in your sshd configuration file, usually at > > > /etc/ssh/sshd_config. > > > > > > Anything here look promising? > > > > > > > > > -- > > > Ben Escoto > > > > > > > _______________________________________________ > > Rdiff-backup mailing list > > Rdiff-backup@keywest.Stanford.EDU > > http://keywest.Stanford.EDU/mailman/listinfo/rdiff-backup > > > > --- > Jason Piterak > System Architect > CIS Technical Services > 33 Main St., Suite 302 > Nashua, NH 03064 > (603) 889-4684 - FAX (603) 889-0534 > > > > > -----Original Message----- > > From: rdiff-backup-admin@keywest.Stanford.EDU > > [mailto:rdiff-backup-admin@keywest.Stanford.EDU]On Behalf Of > > mike wolman > > Sent: Thursday, November 22, 2001 7:33 AM > > To: Ben Escoto > > Cc: rdiff-backup@keywest.Stanford.EDU > > Subject: Re: secure remote backups > > > > > > Hi Ben, > > > > I will give your suggestions a try, I am not too keen on > > opening up root ssh access on the remote machines but i will > > give your other suggestions a try. > > > > Thanks, > > > > Mike. > > > > On Wed, 21 Nov 2001, Ben Escoto wrote: > > > > > >>>>> "MW" == mike wolman > > > >>>>> wrote the following on Wed, 21 Nov 2001 14:41:15 +0000 (GMT) > > > > > > MW> Hi Ben, I have tried your suggestion however when i try to ssh > > > MW> and su i get the following problem from su: standard > > in must be > > > MW> a tty > > > > > > MW> I have had a hunt for anybody else trying to run su > > from ssh but > > > MW> have not found a solution. > > > > > > Hmm, I think something like the ssh-then-su method still could work, > > > but you would need some more complicated wrapper... Ok, how about > > > these suggestions instead: > > > > > > 1. Suid script that runs rdiff-backup --server. I think you would > > > have to create another user id, and make sure only that user has > > > access to the script. > > > > > > 2. Instead of running rdiff-backup on machine A and trying > > to get it > > > to log in to machine B which doesn't accept ssh root logins, run > > > rdiff-backup on machine B (after you 'su' normally) > > with machine A > > > being remote. > > > > > > 3. Reconfigure ssh on the remote machine to accept root logins. To > > > do this, make sure the line > > > > > > PermitRootLogin yes > > > > > > appears in your sshd configuration file, usually at > > > /etc/ssh/sshd_config. > > > > > > Anything here look promising? > > > > > > > > > -- > > > Ben Escoto > > > > > > > _______________________________________________ > > Rdiff-backup mailing list > > Rdiff-backup@keywest.Stanford.EDU > > http://keywest.Stanford.EDU/mailman/listinfo/rdiff-backup > > > From bescoto@stanford.edu Tue Nov 27 21:33:32 2001 From: bescoto@stanford.edu (Ben Escoto) Date: Tue, 27 Nov 2001 13:33:32 -0800 Subject: secure remote backups In-Reply-To: Your message of "Tue, 27 Nov 2001 11:14:11 EST." Message-ID: <200111272133.fARLXWj02236@folly.stanford.edu> --==_Exmh_1146429824P Content-Type: text/plain; charset=us-ascii >>>>> "JP" == Jason Piterak >>>>> wrote the following on Tue, 27 Nov 2001 11:14:11 -0500 JP> Ben, Haven't had a chance to dig into rdiff-backup lately, been JP> too busy with other things. But, I tried your idea of negative JP> --exclude regex parameters to do positive matches (eg: backup JP> all archive files) and couldn't get it to work... JP> Here's what I tried (regex courtesy of our local Perl guru): JP> --exclude '^(.*?\.(?!(tar|rpm|tgz|gz|z|bz2|Z)).*?|[^\.]*?)$' Hmm, is it possible there is a bug in python 2.2's regular expressions? Please confirm, and if I'm not overlooking something stupid I will submit a bug report on Python's web site. So, on my version of Python (v2.2b) I get this behavior: >>> re.match('^a*?$', 'foo') The expression ^a*?$ is only supposed to match strings composed entirely of a's, but here it matches 'foo'. In an earlier version of Python (2.0c1): >>> re.match('^a*?$', 'foo') >>> At least there is some inconsistency between versions. Is the new behavior a bug? It would appear so, but I not really a regular expression person (perhaps your perl guy could comment?). Anyway, I stumbled upon this because your expression above appears to match everything the way python is interpreting it. -- Ben Escoto --==_Exmh_1146429824P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Exmh version 2.2 06/23/2000 iD8DBQE8BAaM+owuOvknOnURAhoDAJ97izF3Fx51Pkbn96aHNZyXM29SiQCcDnTo qeV3T085uvZRE7KO3dk1UYI= =+jUu -----END PGP SIGNATURE----- --==_Exmh_1146429824P-- From bescoto@stanford.edu Tue Nov 27 21:45:22 2001 From: bescoto@stanford.edu (Ben Escoto) Date: Tue, 27 Nov 2001 13:45:22 -0800 Subject: secure remote backups In-Reply-To: Your message of "Tue, 27 Nov 2001 17:35:42 GMT." Message-ID: <200111272145.fARLjMZ02274@folly.stanford.edu> --==_Exmh_1147638080P Content-Type: text/plain; charset=us-ascii >>>>> "MW" == mike wolman >>>>> wrote the following on Tue, 27 Nov 2001 17:35:42 +0000 (GMT) MW> Hi Jason, I am playing with a suid wrapper for rdiff, then MW> sshing in as a backup user and running the wrapper script, as MW> linux refuses to run scripts as suid, i am playing doing it with MW> very limited c knowledge, and with a pile of other stuff MW> mounting in the inbox i have not had a chance to get it setup. I was discussing something similar to this with a user. He wanted something like a --restrict-to commandline parameter or environment variable so that rdiff-backup could run more safely suid root. Suppose machine A is backing up to machine B. He, like you, didn't want machine A logging into machine B as root all the time. If someone compromised machine A, they would get root on machine B immediately by, for instance, mirroring the /etc/passwd file or whatever. So he wanted machine A to log into machine B as a user, but then switch to root in a mode that only allowed for the writing to certain directories. With a --restrict-to option, he could make a suid script that would run rdiff-backup with this option, guaranteeing that important system files could not be overwritten but still allowing rdiff-backup to change ownership (which requires root). This sounds like a good idea to me, but there seems to be some technical problems. The server could check each pathname on each read/write request to make sure that it started with the appropriate directory, but a user could get around this will symlinks. As in, he symlinks /safe/directory/foo to /etc/passwd, and then gets rdiff-backup to read /safe/directory/foo, thus reading /etc/passwd. rdiff-backup could stat each file immediately before doing any reading/writing to make sure it isn't a symlink, but this seems like a lot of overhead, and even then a user could create the symlink after the statting but before the reading. So to sum it up, this seems like a useful idea, but I don't see any way of actually implementing it correctly. Anyone have thoughts on the matter? -- Ben Escoto --==_Exmh_1147638080P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Exmh version 2.2 06/23/2000 iD8DBQE8BAlu+owuOvknOnURAmKHAJ4uMHfnKquAP7S+xMS+A0GSvgQ8LACfR7vW mswNyIIznShwSkbq4LgrPgY= =UWMT -----END PGP SIGNATURE----- --==_Exmh_1147638080P--