instead of the disk size of the file sent. Since the log file
is intended to provide data for anonymous ftp traffic accounting,
the disk size of the file isn't really informative in this case.
PR: bin/72687
Submitted by: Oleg Koreshkov
MFC after: 1 week
if sendfile() transferred some data before throwing
a error condition because sendfile() won't move the
file offset for read() to start from.
MFC after: 2 weeks
Do not unconditionally fork() after accept(). accept() can
return -1 due to an interrupted system call (i.e. SIGCHLD).
If we fork in that case ftpd can get into an
accept()/SIGCHLD/fork/[fail]/repeat loop.
Reported-by: fabian <fabian.duelli@bluewin.ch>
Obtained from: DragonflyBSD
MFC after: 1 month
of releases. The -DNOCRYPT build option still exists for anyone who
really wants to build non-cryptographic binaries, but the "crypto"
release distribution is now part of "base", and anyone installing from a
release will get cryptographic binaries.
Approved by: re (scottl), markm
Discussed on: freebsd-current, in late April 2004
(and it appears possible throughout ftpd(8) source.)
It is not a mere issue of style: Null pointers in C
seem to have been mistaken one way or another quite often.
of the current user, not root. This will allow neat things
like matching anonymous FTP data traffic with a single ipfw(8)
rule:
ipfw add ... tcp from any to any uid ftp
Note that the control connection socket still belongs to the
user ftpd(8) was started from, usually root.
PR: bin/65928
Submitted by: Eugene Grosbein <eugen at grosbein.pp.ru>
MFC after: 1 month
Reducing "/+./" strings to "/"
Reducing "/[^/]+/../" to "/"
o Don't send an OACK when the result of the [RW]RQ is an error.
These changes allow tftpd to interact with pxelinux.bin from the syslinux
package.
Whilst the path reducing code doesn't properly handle situations where the
path component before the "/../" is a symlink to (say) ".", I would suggest
that it does the right thing in terms of the clients perception of what
their path string actually represents. This seems better than using
realpath() and breaking environments where symlinks point outside of the
directory hierarchy that tftpd is configured to allow.
(and that is for now being worked around by a binutils patch).
The rtld code tested &_DYNAMIC against 0 to see whether rtld itself
was built as PIC or not. While the sparc64 MD code did not rely
on the preset value of the GOT slot for _DYNAMIC any more due
to previous binutils changes, it still used to not be 0, so
that this check did work. The new binutils do however initialize
this slot with 0. As a consequence, rtld would not properly initialize
itself and crash.
Fix that by introducing a new macro, RTLD_IS_DYNAMIC, to take the role
of this test. For sparc64, it is implemented using the rtld_dynamic()
code that was already there. If an architecture does not provide its
own implementation, we default to the old check.
While being there, mark _DYNAMIC as a weak symbol in the sparc64
rtld_start.S. This is needed in the LDSCRIPT case, which is however
not currently supported for want of an actual ldscript.
Sanity checked with md5 on alpha, amd64, i386 and ia64.
stable ld.so. We need to revisit the rtld-elf/sparc64/rtld_start.S
rev. 1.5 and rtld-elf/sparc64/rtld_machdep.h rev. 1.5, which was
suppose to allow stock Binutils 2.13 (and later) to be used.
