Upgrade to 2.3.1

This commit is contained in:
espie 1999-04-18 20:59:00 +00:00
parent 9ffed40a72
commit 6eeafca4eb
4 changed files with 8 additions and 181 deletions

View File

@ -1,13 +1,11 @@
# $OpenBSD: Makefile,v 1.8 1999/04/09 02:20:14 espie Exp $
# $OpenBSD: Makefile,v 1.9 1999/04/18 20:59:00 espie Exp $
#
DISTNAME= rsync-2.3.0
DISTNAME= rsync-2.3.1
CATEGORIES=net
NEED_VERSION=1.60
PATCH_STRIP=-p1
MAINTAINER= espie@openbsd.org

View File

@ -1,3 +1,3 @@
SHA1 (rsync-2.3.0.tar.gz) = 3a94855f55897866af8960aaa30f6eded0db6311
RMD160 (rsync-2.3.0.tar.gz) = 8fa61afa6da9b7eb9977c7962eee38d38e723337
MD5 (rsync-2.3.0.tar.gz) = 88e93cf2b10ca482f25c934fca1eb245
SHA1 (rsync-2.3.1.tar.gz) = ed79191f1f3b503204d0bdd3a9f7e08b04f642f4
RMD160 (rsync-2.3.1.tar.gz) = 9bc949e410a06e9ecc827d7377959758357dcacd
MD5 (rsync-2.3.1.tar.gz) = 907a0ae01417d54e53cb84b069ba1620

View File

@ -1,116 +0,0 @@
diff -u -r --new-file --exclude=CVS rsync-2.3.0/cleanup.c rsync-2.3.1/cleanup.c
--- rsync-2.3.0/cleanup.c Thu Nov 26 03:24:39 1998
+++ rsync-2.3.1/cleanup.c Wed Apr 7 01:04:16 1999
@@ -30,10 +30,13 @@
static int cleanup_fd1, cleanup_fd2;
static struct map_struct *cleanup_buf;
static int cleanup_pid = 0;
+extern int io_error;
void _exit_cleanup(int code, const char *file, int line)
{
extern int keep_partial;
+
+ if (code == 0 && io_error) code = RERR_FILEIO;
signal(SIGUSR1, SIG_IGN);
diff -u -r --new-file --exclude=CVS rsync-2.3.0/clientserver.c rsync-2.3.1/clientserver.c
--- rsync-2.3.0/clientserver.c Tue Mar 16 08:23:11 1999
+++ rsync-2.3.1/clientserver.c Wed Apr 7 01:04:16 1999
@@ -417,6 +417,7 @@
int daemon_main(void)
{
extern char *config_file;
+ extern int orig_umask;
char *pid_file;
if (is_a_socket(STDIN_FILENO)) {
@@ -447,16 +448,19 @@
rprintf(FINFO,"rsyncd version %s starting\n",VERSION);
if (((pid_file = lp_pid_file()) != NULL) && (*pid_file != '\0')) {
- FILE *f;
+ char pidbuf[16];
+ int fd;
int pid = (int) getpid();
cleanup_set_pid(pid);
- if ((f = fopen(lp_pid_file(), "w")) == NULL) {
+ if ((fd = do_open(lp_pid_file(), O_WRONLY|O_CREAT|O_TRUNC,
+ 0666 & ~orig_umask)) == -1) {
cleanup_set_pid(0);
fprintf(stderr,"failed to create pid file %s\n", pid_file);
exit_cleanup(RERR_FILEIO);
}
- fprintf(f, "%d\n", pid);
- fclose(f);
+ slprintf(pidbuf, sizeof(pidbuf), "%d\n", pid);
+ write(fd, pidbuf, strlen(pidbuf));
+ close(fd);
}
start_accept_loop(rsync_port, start_daemon);
diff -u -r --new-file --exclude=CVS rsync-2.3.0/generator.c rsync-2.3.1/generator.c
--- rsync-2.3.0/generator.c Tue Mar 16 08:23:11 1999
+++ rsync-2.3.1/generator.c Wed Apr 7 01:04:16 1999
@@ -317,7 +317,8 @@
}
if (skip_file(fname, file, &st)) {
- set_perms(fname,file,&st,1);
+ if (fnamecmp == fname)
+ set_perms(fname,file,&st,1);
return;
}
diff -u -r --new-file --exclude=CVS rsync-2.3.0/main.c rsync-2.3.1/main.c
--- rsync-2.3.0/main.c Tue Mar 16 08:23:11 1999
+++ rsync-2.3.1/main.c Wed Apr 7 01:04:16 1999
@@ -208,7 +208,7 @@
return name;
}
- if (flist->count == 1)
+ if (flist->count <= 1)
return name;
if (do_mkdir(name,0777 & ~orig_umask) != 0) {
@@ -355,8 +355,8 @@
recv_exclude_list(f_in);
flist = recv_file_list(f_in);
- if (!flist || flist->count == 0) {
- rprintf(FERROR,"server_recv: nothing to do\n");
+ if (!flist) {
+ rprintf(FERROR,"server_recv: recv_file_list error\n");
exit_cleanup(RERR_FILESELECT);
}
diff -u -r --new-file --exclude=CVS rsync-2.3.0/receiver.c rsync-2.3.1/receiver.c
--- rsync-2.3.0/receiver.c Tue Mar 16 08:23:11 1999
+++ rsync-2.3.1/receiver.c Wed Apr 7 01:04:16 1999
@@ -417,6 +417,9 @@
fd2 = do_open(fnametmp,O_WRONLY|O_CREAT|O_EXCL,
file->mode & INITACCESSPERMS);
+ /* in most cases parent directories will already exist
+ because their information should have been previously
+ transferred, but that may not be the case with -R */
if (fd2 == -1 && relative_paths && errno == ENOENT &&
create_directory_path(fnametmp) == 0) {
fd2 = do_open(fnametmp,O_WRONLY|O_CREAT|O_EXCL,
@@ -474,7 +477,7 @@
for (i = 0; i < flist->count; i++) {
file = flist->files[i];
if (!file->basename || !S_ISDIR(file->mode)) continue;
- recv_generator(f_name(file),flist,i,-1);
+ recv_generator(local_name?local_name:f_name(file),flist,i,-1);
}
if (verbose > 2)
diff -u -r --new-file --exclude=CVS rsync-2.3.0/version.h rsync-2.3.1/version.h
--- rsync-2.3.0/version.h Tue Mar 16 08:23:18 1999
+++ rsync-2.3.1/version.h Wed Apr 7 01:09:25 1999
@@ -1 +1 @@
-#define VERSION "2.3.0"
+#define VERSION "2.3.1"

View File

@ -1,64 +1,9 @@
$OpenBSD: SECURITY,v 1.2 1999/04/09 02:20:16 espie Exp $
$OpenBSD: SECURITY,v 1.3 1999/04/18 20:59:02 espie Exp $
${WRKDIR}/receiver.c
call to mktemp (wrapper function do_mktemp) does seem to be correct.
The server makes extensive use of strlcpy/strlcat/snprintf.
rsync-2.3.1 came out after ports freeze. A small patch was included in this
port that fixes the relevant security advisory (the patched version is
functionally identical to rsync-2.3.1, but the documentation has not been
upgraded for size reasons... get the real thing !)
-------------------------------------------------------------------
From tridge@samba.org Thu Apr 8 02:19:54 CEST 1999
Subject: rsync 2.3.1 release - security fix
I discovered a security hole in rsync yesterday and have released
rsync 2.3.1 to fix it.
The new version and patches against the last version are available at
http://rsync.samba.org/ or ftp://rsync.samba.org/pub/rsync/
The problem happened when all of these conditions held true:
1) the source file list contains exactly one filename and that
is the name of an empty directory
2) the source directory name is specified on the command line
as "somedir/" or "somedir/." or "." not as "somedir"
3) the destination directory doesn't exist
4) you have recursion and permission transfer enabled (the -a option
will do this)
5) the working directory of the receiving process is not the
destination directory (this happens when you do remote rsync
transfers)
(the short summary is that you need to be transferring an empty
directory into a non-existent directory)
In that case (which is quite rare) the permissions from the empty
directory in the source file list were set on the working directory of
the receiving process. In the case of a remote rsync over rsh or ssh
this means that the permissions on your home directory are changed to
those of the empty directory you are transferring.
This is a serious bug (and security hole) as it may change your home
directory permissions to allow other users access to your files. A
user can't exploit this hole deliberately to gain privileges (ie. this
is not an "active" security hole) but a system administrator could
easily be caught by the bug and inadvertently compromise the security
of their system.
To see if you have been hit by this bug you should look at the
permissions on your home directory. If they are not what you expect
then perhaps you have been bitten by this bug.
The fix is to chmod your home directory back to the correct
permissions and upgrade to rsync 2.3.1. The bug is in the receiving
side of rsync, so it is quite safe to continue to use older anonymous
rsync servers as long as you upgrade your client.
This bug has been present in all versions of rsync. I apologize for
any inconvenience.
Tridge
rsync upto 2.3.0 has a security hole. If rsync --version is less or equal
to that, you should upgrade.