similar to: openssh bugs in snapshot for nextstep (fwd)

Yo Andrew! What version of Openssh are you trying? RGDS GARY On Mon, 12 Jun 2000, Andrew McGill wrote: > Date: Mon, 12 Jun 2000 15:26:53 +0200 > From: Andrew McGill <andrewm at datrix.co.za> > To: djm at ibs.com.au > Cc: gem at rellim.com > Subject: Openssh on SCO Openserver Release 5 > > Hi there > > Your e-mail address appears in the README for openssh,

https://bugzilla.samba.org/show_bug.cgi?id=8001 Summary: buffer overflow in recv_file_entry (maxpathlen doesn't works) Product: rsync Version: 3.0.8 Platform: All OS/Version: FreeBSD Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org

Rsync 2.5.6 has a problem with pathnames or filenames longer than 255. I redefined them in rsync.h, which generated errors on make pointing to the previous definitions which look fine. Any ideas on where to check next? Here's the error I got trying to rsync: receiving file list ... done

This is a small/trivial patch to get HURD to _compile_ (I haven't gotten PRNG to work yet) openssh. All it does is define MAXHOSTNAMELEN in defines.h if it isn't already defined (there may need to be a library loaded first, or you may want to incorporate that patch into canohost.c instead of defines.h). Anyway, small patch for canohost.c and defines.h because HURD doesn't use

Full_Name: Murray Stokely Version: 2.10.1 OS: Linux Submission from: (NULL) (216.239.45.4) The Defn.h header includes limits.h for PATH_MAX and then checks if it hasn't been defined and if not sets something manually. Some of the R code uses PATH_MAX but a lot of other functions in unix/sys-unix.c and main/startup.c just hardcodes a limit of 256 characters. In my environment this is not

https://bugzilla.mindrot.org/show_bug.cgi?id=1993 alex at testcore.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alex at testcore.net Version|5.9p1 |6.2p1 --- Comment #1 from alex at testcore.net --- Also

hello, asteriskers: I compiled asterisk under arm-linux. i am using asterisk 1.4.2. i can run ./configure and menuselect with embedded modules. but running make comes out errors: ranlib libmxml.a make[3]: Leaving directory `/usr/src/asterisk-1.4.2/menuselect/mxml' cc -Wall -o menuselect.o -g -c -D_GNU_SOURCE menuselect.c cc -Wall -o menuselect_curses.o -g -c -D_GNU_SOURCE

This patch adds some queue limit parameters into block drive. And inits them for sg block drive. Some interfaces are also added for accessing them. Signed-off-by: Cong Meng <mc at linux.vnet.ibm.com> --- block/raw-posix.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++++ block_int.h | 4 +++ blockdev.c | 15 +++++++++++++ hw/block-common.h | 3 ++ 4 files

This patch adds some queue limit parameters into block drive. And inits them for sg block drive. Some interfaces are also added for accessing them. Signed-off-by: Cong Meng <mc at linux.vnet.ibm.com> --- block/raw-posix.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++++ block_int.h | 4 +++ blockdev.c | 15 +++++++++++++ hw/block-common.h | 3 ++ 4 files

Hi, I get below error: --------------------------------- In file included from /usr/local/build/llvm/lib/System/platform/Path.cpp:23, from /usr/local/src/llvm/lib/System/Path.cpp:27: /usr/local/build/llvm/lib/System/platform/../Unix/Path.cpp: In member function `bool llvm::sys::Path::create_directory(bool)': /usr/local/build/llvm/lib/System/platform/../Unix/Path.cpp:343:

https://bugzilla.samba.org/show_bug.cgi?id=5235 Summary: buffer overflow in receive_file_entry Product: rsync Version: 2.6.9 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: rsync@ofdan.co.uk

Hello, Using PATH_MAX is not a good idea: POSIX says that that definition is facultative, in case the system does not impose any limit on path length. Some systems may also set PATH_MAX to a quite high value, and we would hence consume a lot of stack. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, I recently downloaded and built dovecot-2.2.2 and dovecot-2.2-pigeonhole-0.4.0 on GNU/Linux and GNU/Hurd. The changes needed will be sent to the Debian maintainer shortly. Latest Debian release is 2.1.7-7 and dovecot-2.1-pigeonhole-0.3.1. When building dovecot-2.2.2 there were no PATH_MAX problems on GNU/Hurd, thank you for that. However, pigeonhole 0.4.0 had one remaining PATH_MAX construct.

Summary: you can exploit a single-byte buffer overrun to gain root privs. When, half a day after releasing version 2.2beta37 of the Linux nfs server, I received a message from Larry Doolittle telling me that it was still vulnerable to the root exploit posted to bugtraq, I was ready to quit hacking and start as a carpenter... Tempting as that was, I didn''t, and started looking for the

In an effort to get my long-desired move-files functionality into rsync, I have created a version of my patch that runs as an extra pass at the end of the processing. This results in a simpler set of changes to rsync. I still think it would be nice to have incremental deletions during large transfers (as my first patch provides), but acceptance of this patch would relegate such quibbling to a

blkid_probe_get_wholedisk_devno() isn''t available in some older versions of libblkid. It was used to work around an old bug in blkid_devno_to_wholedisk(), but that has been fixed since 5cd0823 libblkid: fix blkid_devno_to_wholedisk(), present in util-linux 2.17 and beyond. If we happen to be missing that fix, the worst that happens is that we''d fail to detect that a device is

On Tuesday 23 September 2014 17:20:35 Hu Tao wrote: > Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> > --- > daemon/inotify.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) While I'd personally get rid of PATH_MAX at all, I understand the Linux inotify implementation relies on it... > > diff --git a/daemon/inotify.c b/daemon/inotify.c > index

This is needed as the basis for the readlink -f option. Signed-off-by: Ben Hutchings <ben at decadent.org.uk> --- --- a/usr/include/stdlib.h +++ b/usr/include/stdlib.h @@ -92,4 +92,6 @@ static __inline__ int grantpt(int __fd) return 0; /* devpts does this all for us! */ } +__extern char *realpath(const char *, char *); + #endif /* _STDLIB_H */ --- a/usr/klibc/Kbuild +++

Hello folks, Is it possible to extend log message as large as PATH_MAX? Current length of message format including file path is small against linux PATH_MAX, 4096. diff --git a/log.c b/log.c index ad12930..95df4a9 100644 --- a/log.c +++ b/log.c @@ -359,7 +359,7 @@ log_redirect_stderr_to(const char *logfile) log_stderr_fd = fd; } -#define MSGBUFSIZ 1024 +#define MSGBUFSIZ 5192 void

I've recently encountered this issue which was discussed here about a year ago. I'm not sure if anyone has a fix for this, but I thought I would post my workaround here. Since the topic is old, I'm summarising the problem .. basically it involves rsync creating large numbers of files with a leading ".." when syncing to an apple network share via afp. The essence of the