Re: should rsync also be called ssync?
On Thu, Mar 01, 2001 at 06:31:49PM +1100, Andrew Tridgell wrote: It would also ease confusion as everybody begins to think "r* means bad security". I think this argument is a little weak. There are 143 commands starting with r on my system. Only 2 or 3 of them suffer from the rsh style security problems. Right, but in particular the network commands that rsync is perceived to be among. I assume the "r" in rsync was derived from the "r" in rsh and probably many other people do too. On Thu, Mar 01, 2001 at 01:16:29PM +1100, Martin Pool wrote: On 28 Feb 2001, Dave Dykstra [EMAIL PROTECTED] wrote: ... I guess this is getting off the track, but I think that is a kind of wierd situation. If you're allowing rhosts login for rsh, why not allow it for ssh? It is allowed but the problem is that it takes a while for people to figure out that they also need to have a "known_hosts" entry for the client machine because only RhostsRSAAuthentication is allowed. Also, the client isn't always setuid-root which is also needed for .rhosts. ... Why not just do it as a shell script? #! /bin/sh rsync -e ssh "$@" The GNU Standards (for what they're worth) deprecate having program behaviour depend on argv[0], and I'm inclined to agree, especially because you're doing to support a program that really should be dead by now. That's an interesting idea that I hadn't thought of for this case. I'm assuming you mean including that shell script in the standard package and not just suggesting that people do this on their own. I'll consider it when I get into it, but I can think of a couple minor disadvantages of doing it as a shell script: 1. It can be tricky to locate another program sometimes. It's not always in the PATH. An absolute path can be used but then the package isn't relocatable without edits and so far the rsync package is. A counter argument of course is that people could just edit the script to relocate it. 2. It's slightly slower on startup. Anybody know GNU's reasons against having program behavior depend on argv[0]? I guess GNU has had a lot of headaches with people want to install things with a "g" prefix or not, that might explain it. - Dave Dykstra
Re: should rsync also be called ssync?
We're having a debate in which some are advocating changing a long-established and respected utility name, with the sole purpose of placating ignorant, inflexible-minded fools. Did anybody notice this? Tim Conway [EMAIL PROTECTED] 303.682.4917 Philips Semiconductor - Colorado TC 1880 Industrial Circle Suite D Longmont, CO 80501
Re: should rsync also be called ssync?
I spoke too harshly anyway. At the start, it looked like just an alias, and I couldn't figure out why the code needed to be changed, when we could have a script called ssync, containing (after the interpreter line) exec rsync $@ . The only reason I could see to put the change into the code would be to change what's seen in the process table, so some idiot who judges programs by their name won't kill it. I personally would rather see spare brain ticks spent on a speeding the construction of file lists. I wish I had the skills to help. Tim Conway [EMAIL PROTECTED] 303.682.4917 Philips Semiconductor - Colorado TC 1880 Industrial Circle Suite D Longmont, CO 80501 [EMAIL PROTECTED] on 03/01/2001 02:56:02 PM To: Tim Conway/LMT/SC/PHILIPS@AMEC cc: [EMAIL PROTECTED]@SMTP Subject:Re: should rsync also be called ssync? Classification: On Thu, Mar 01, 2001 at 01:54:04PM -0600, [EMAIL PROTECTED] wrote: We're having a debate in which some are advocating changing a long-established and respected utility name, with the sole purpose of placating ignorant, inflexible-minded fools. Did anybody notice this? Not changing. Just adding an alias. - Dave
Re: should rsync also be called ssync?
On Wed, Feb 28, 2001 at 11:04:56AM +1100, Martin Pool wrote:
Dave Dykstra wrote:
How does everybody (especially Martin and Tridge) feel about the idea of
rsync defaulting to "-e ssh" if it is invoked under the name ssync? Around
here everybody is being told they should stop using r* commands and start
using the s* equivalents so it seems a natural changeover. If there is
general agreement, I'm willing to implement it and change the default
installation to install symlinks at bin/ssync and man/man1/ssync.1.
Personally I don't see any need to build a separate binary when a
shell script or alias would do just as well.
I certainly wasn't talking about building a separate binary, I was just
talking about putting a symlink called 'ssync' in the standard install if
ssh was found.
Also, I think in any
given system people are going to either be using rsh or ssh, not both.
(Does *anyone* really use rsh rather than daemon or ssh anymore?)
That's very much not the case around here yet. Most people use only the
intranet and are just starting to get aquainted with ssh because of a
push by corporate security. It's going to take quite a while before
people to transition, and it would be very handy to be able to choose
rsync or ssync commands to choose a different default. It would also
ease confusion as everybody begins to think "r* means bad security".
Regarding Phil's comment about there not being a need to use up the name
"ssync" in the command name space, I argue that a lot of people who have
heard of rsync and ssh would expect ssync to be a secure version of rsync
and would be confused if somebody used that name for something else.
It seems fairly clear that it would be good to change over to SSH as
the default:
* for people who can use either, it's better to be secure by default.
* people still using rsh should be gently encouraged to move to ssh
unless they speifically choose to stay.
* ssh can (optionally) fall back to using rsh if there's no ssh
server listening.
* forgetting to set RSYNC_RSH or -e is a pretty common problem for
people wanting to start using it.
* if all else fails, you can do
--with-default-rsh=/etc/alternatives/remoteshell, or ln -s rsh shh
However, I can imagine this causing small problems for people building
binary distributions.
I don't mind there being a configure option, but I do a wide binary
distribution and would not be able to enable the option and I would object
to it being the default because of the number of things it could break.
For example, I'll expect I'll have a lot of cases where both sshd and rsh
will be enabled for the same server so it won't fall back to rsh, but ssh
will prompt for a password but rsh won't.
On Wed, Feb 28, 2001 at 04:31:44PM +1100, Martin Pool wrote:
This is my idea of the patch. Note that this would make ssh the
default for 2.4.7, unless you specify otherwise at configure or run
time.
...
Index: configure.in
===
RCS file: /data/cvs/rsync/configure.in,v
retrieving revision 1.67
diff -p -c -r1.67 configure.in
*** configure.in 2001/02/24 01:37:48 1.67
--- configure.in 2001/02/28 05:15:17
*** AC_PROG_CC
*** 42,47
--- 42,62
AC_PROG_INSTALL
AC_SUBST(SHELL)
+ AC_ARG_WITH(rsh,
+ [ --with-rsh=COMMAND use alternative remote shell program],
+ [ RSYNC_RSH="$withval" ],
+ [ RSYNC_RSH=ssh ] )
I object to having RSYNC_RSH be set to ssh by default. I also object to
it causing an error if ssh is not installed.
I think the name --with-default-rsh is better.
+
+ AC_MSG_CHECKING("for $RSYNC_RSH in \$PATH")
+ if locn=`which $RSYNC_RSH`
"which" is not a standard function. It is not on three of the system
types I build binaries for. Use AC_PATH_PROG(VARIABLE, PROG-TO-CHECK-FOR).
+ then
+ AC_MSG_RESULT($locn)
+ else
+ AC_MSG_RESULT(no)
+ AC_MSG_WARN("$RSYNC_RSH does not seem to be in \$PATH on this machine")
+ fi
+ AC_DEFINE_UNQUOTED(RSYNC_RSH, "$RSYNC_RSH", [Default remote shell program to use])
+
AC_CHECK_PROG(HAVE_REMSH, remsh, 1, 0)
AC_DEFINE_UNQUOTED(HAVE_REMSH, $HAVE_REMSH)
...
Index: rsync.h
===
RCS file: /data/cvs/rsync/rsync.h,v
retrieving revision 1.97
diff -p -c -r1.97 rsync.h
*** rsync.h 2001/02/23 01:02:55 1.97
--- rsync.h 2001/02/28 05:15:21
*** enum logcode {FNONE=0, FERROR=1, FINFO=2
*** 73,84
#include "config.h"
- #if HAVE_REMSH
- #define RSYNC_RSH "remsh"
- #else
- #define RSYNC_RSH "rsh"
- #endif
-
#include sys/types.h
#ifdef HAVE_UNISTD_H
--- 73,78
Here's one problem I see: you're setting HAVE_REMSH but aren't using it
anymore. You need to have it take precedence in the setting of RSYNC_RSH
in configure.
Another problem is that the RSYNC_RSH
Re: should rsync also be called ssync?
On 28 Feb 2001, Dave Dykstra [EMAIL PROTECTED] wrote:
That's very much not the case around here yet. Most people use only the
intranet and are just starting to get aquainted with ssh because of a
push by corporate security. It's going to take quite a while before
people to transition, and it would be very handy to be able to choose
rsync or ssync commands to choose a different default.
I think that's probably better done as a site-specific thing at Bell
Labs, then.
It would also ease confusion as everybody begins to think "r* means
bad security".
I can understand what you mean, but I don't think that would help the
situation.
After all, consider that "r* means `remote'" is generally true, but
rsync has nothing to do with sync(1). And I don't want to give
anybody else the idea that plain rsync is necessarily as insecure as
rsh.
I don't mind there being a configure option, but I do a wide binary
distribution and would not be able to enable the option and I would
object to it being the default because of the number of things it
could break. For example, I'll expect I'll have a lot of cases
where both sshd and rsh will be enabled for the same server so it
won't fall back to rsh, but ssh will prompt for a password but rsh
won't.
I guess this is getting off the track, but I think that is a kind of
wierd situation. If you're allowing rhosts login for rsh, why not
allow it for ssh?
I object to having RSYNC_RSH be set to ssh by default. I also object to
it causing an error if ssh is not installed.
This is really the heart of the question: should we ever change the
default in the upstream distribution to give people a prod to move to
ssh? Or, should we wait for 2.5 (if any) or 3.0 to do that?
I think we should change it, and sooner rather than later though not
necessarily right now.
I think the name --with-default-rsh is better.
Yes, that's probably a better name.
Also, as you might have seen in a patch a while ago, I want to make
rsync give a better message if the remote shell fails. This should
make it clearer to people what's going wrong.
+ AC_MSG_CHECKING("for $RSYNC_RSH in \$PATH")
+ if locn=`which $RSYNC_RSH`
"which" is not a standard function. It is not on three of the system
types I build binaries for. Use AC_PATH_PROG(VARIABLE,
PROG-TO-CHECK-FOR).
Thanks, I realized that just after I posted.
Another problem is that the RSYNC_RSH define is used in main.c (~ line 184)
to determine whether or not the blocking_io option should be turned on.
I'm not sure how else to handle it unless you explicitly parse the name
to see if the base portion starts with "r". However, that may break some
people's scripts if they have written their own '-e' scripts which happen
to start with "r". It may be worth it, however.
That's a good point. The whole non-blocking area is too ugly for
words, and perhaps a reason not to change anything about the remote
shell until 3.0.
I still plan to contribute a patch to add a --with-default-ssh configure
option which will default to ssh in the PATH, and if ssh is found it will
install symlinks at bin/ssync and man/man1/ssync.1. I expect to set a
RSYNC_SSH define and use that if arg0 starts with "s". I probably won't
get to it until next week though.
Why not just do it as a shell script?
#! /bin/sh
rsync -e ssh "$@"
The GNU Standards (for what they're worth) deprecate having program
behaviour depend on argv[0], and I'm inclined to agree, especially
because you're doing to support a program that really should be dead
by now.
--
Martin Pool, Human Resource
Linuxcare. Inc. +61 2 6262 8990
[EMAIL PROTECTED], http://linuxcare.com.au/
Linuxcare. Putting Open Source to work.
Re: should rsync also be called ssync?
It would also ease confusion as everybody begins to think "r* means bad security". I think this argument is a little weak. There are 143 commands starting with r on my system. Only 2 or 3 of them suffer from the rsh style security problems. I don't think anyone is going to abandon rm and route anytime soon :) After all, consider that "r* means `remote'" is generally true I'm rather skeptical about this as well. It is true of rsync, but is not generally applicable. btw, I still think rsh is a completely appropriate program to use in some situations. It is certainly makes much more efficient use of network bandwidth than ssh does. I use ssh everywhere largely because it is so convenient. A lot of the time when I use it I could use rsh without any security implications, but I don't because rsh doesn't offer things like auto X forwarding. I also know that quite a few people do use rsync over rsh as we got a pile of bug reports when I broke rsync/rsh on Solaris with the first non-blocking patch. We certainly must offer an easy way to get the current behaviour. Cheers, Tridge
rsync should use ssh by default (was Re: should rsync also be called ssync?)
On the whole, I think the time when people should be using rsh is long
past, and it's about time to add a --with-default-rsh=[ssh] option to
configure.
This is my idea of the patch. Note that this would make ssh the
default for 2.4.7, unless you specify otherwise at configure or run
time.
http://www.openssh.com/images/shherrif.jpg
--
Martin Pool, Human Resource
Linuxcare. Inc. +61 2 6262 8990
[EMAIL PROTECTED], http://linuxcare.com.au/
Linuxcare. Putting Open Source to work.
Index: configure.in
===
RCS file: /data/cvs/rsync/configure.in,v
retrieving revision 1.67
diff -p -c -r1.67 configure.in
*** configure.in2001/02/24 01:37:48 1.67
--- configure.in2001/02/28 05:15:17
*** AC_PROG_CC
*** 42,47
--- 42,62
AC_PROG_INSTALL
AC_SUBST(SHELL)
+ AC_ARG_WITH(rsh,
+ [ --with-rsh=COMMAND use alternative remote shell program],
+ [ RSYNC_RSH="$withval" ],
+ [ RSYNC_RSH=ssh ] )
+
+ AC_MSG_CHECKING("for $RSYNC_RSH in \$PATH")
+ if locn=`which $RSYNC_RSH`
+ then
+ AC_MSG_RESULT($locn)
+ else
+ AC_MSG_RESULT(no)
+ AC_MSG_WARN("$RSYNC_RSH does not seem to be in \$PATH on this machine")
+ fi
+ AC_DEFINE_UNQUOTED(RSYNC_RSH, "$RSYNC_RSH", [Default remote shell program to use])
+
AC_CHECK_PROG(HAVE_REMSH, remsh, 1, 0)
AC_DEFINE_UNQUOTED(HAVE_REMSH, $HAVE_REMSH)
Index: main.c
===
RCS file: /data/cvs/rsync/main.c,v
retrieving revision 1.123
diff -p -c -r1.123 main.c
*** main.c 2001/02/23 00:48:47 1.123
--- main.c 2001/02/28 05:15:21
*** static void report(int f)
*** 125,131
}
! /* Start the remote shell. */
/* TODO: When the shell exits, look at its return value, as this may
* well tell us if something went wrong in trying to connect to the
* remote machine. Although it doesn't seem to be specified anywhere,
--- 125,131
}
! /* Start the remote shell. cmd may be NULL to use the default. */
/* TODO: When the shell exits, look at its return value, as this may
* well tell us if something went wrong in trying to connect to the
* remote machine. Although it doesn't seem to be specified anywhere,
Index: options.c
===
RCS file: /data/cvs/rsync/options.c,v
retrieving revision 1.51
diff -p -c -r1.51 options.c
*** options.c 2001/02/24 01:39:19 1.51
--- options.c 2001/02/28 05:15:21
*** static void print_rsync_version(int f)
*** 119,128
rprintf(f,
"Copyright (C) 1996-2001 by Andrew Tridgell, Paul Mackerras and
others\n");
rprintf(f, "Capabilities: %d-bit files, %ssocketpairs, "
! "%shard links, %ssymlinks\n\n",
sizeof(int64) * 8,
got_socketpair,
hardlinks, links);
#ifdef NO_INT64
rprintf(f, "WARNING: no 64-bit integers on this platform!\n");
--- 119,130
rprintf(f,
"Copyright (C) 1996-2001 by Andrew Tridgell, Paul Mackerras and
others\n");
rprintf(f, "Capabilities: %d-bit files, %ssocketpairs, "
! "%shard links, %ssymlinks\n",
sizeof(int64) * 8,
got_socketpair,
hardlinks, links);
+ rprintf(f, "Default remote shell: %s\n", RSYNC_RSH);
+ rprintf(f, "\n");
#ifdef NO_INT64
rprintf(f, "WARNING: no 64-bit integers on this platform!\n");
Index: rsync.h
===
RCS file: /data/cvs/rsync/rsync.h,v
retrieving revision 1.97
diff -p -c -r1.97 rsync.h
*** rsync.h 2001/02/23 01:02:55 1.97
--- rsync.h 2001/02/28 05:15:21
*** enum logcode {FNONE=0, FERROR=1, FINFO=2
*** 73,84
#include "config.h"
- #if HAVE_REMSH
- #define RSYNC_RSH "remsh"
- #else
- #define RSYNC_RSH "rsh"
- #endif
-
#include sys/types.h
#ifdef HAVE_UNISTD_H
--- 73,78
Re: should rsync also be called ssync?
Good idea - I'm in favour, although it'll take me a year or two to stop calling it rsync. On Thu, 15 Feb 2001, Dave Dykstra wrote: How does everybody (especially Martin and Tridge) feel about the idea of rsync defaulting to "-e ssh" if it is invoked under the name ssync? Around here everybody is being told they should stop using r* commands and start using the s* equivalents so it seems a natural changeover. If there is general agreement, I'm willing to implement it and change the default installation to install symlinks at bin/ssync and man/man1/ssync.1. - Dave Dykstra -- Robert Scholten Tel: +61 3 8344 5457 Mob: 0412 834 196 School of Physics Fax: +61 3 9347 4783 University of Melbourne email: [EMAIL PROTECTED] Victoria 3010 AUSTRALIA http://www.ph.unimelb.edu.au/~scholten
Re: should rsync also be called ssync?
I actually like the name rsync :) I'd be very happy with a configure option that sets the default remote shell, and I don't mind a argv[0] check that knows about the name ssync, but I'd prefer for the package to still be called "rsync" as I think the name is well enough known that a change at this stage would not be a good idea. btw, if you install as ssync you would have to also install as rsync (presumably a symlink to ssync would be used) as otherwise the remote operation of existing versions would fail. Cheers, Tridge
