long commands into multiple requests. [08:12]
Avoid calling uninitialized function pointers in protocol switch
code. [08:13]
Merry Christmas everybody...
Approved by: so (cperciva)
Approved by: re (kensmith)
Security: FreeBSD-SA-08:12.ftpd, FreeBSD-SA-08:13.protosw
The support for RFC 2640 (UTF8) is optional and rudimentary.
The server just advertises its capability to handle UTF-8 file
names and relies on its own 8-bit cleanness, as well as on
the backward compatibility of UTF-8 with ASCII. So uploaded
files will have UTF-8 names, but the initial server contents
should be prepared in UTF-8 by hand, no on-the-fly conversion
of file names will be done.
PR: bin/111714
Submitted by: Zhang Weiwu <see email in the PR>
MFC after: 1 week
from accept(2) and fork(2). Also close all unneeded fds
in the child process, namely listening sockets for all
address families and the fd initially obtained from accept(2).
(The main ftpd code operates on stdin/stdout anyway as it
has been designed for running from inetd.)
MFC after: 5 days
By default, create a pid file at the standard location, /var/run/ftpd.pid,
in accord with the expected behavior of a stock system daemon.
MFC after: 5 days
The major change is to process STAT sent as an OOB command w/o
breaking the current data transfer. As a side effect, this gives
better error checking in the code performing data transfers.
A lesser, but in no way cosmetic, change is using the flag `recvurg'
in the only signal-safe way that has been blessed by SUSv3. The
other flag, `transflag,' becomes private to the SIGURG machinery,
serves debugging purposes only, and may be dropped in the future.
The `byte_count' global variable is now accounting bytes actually
transferred over the network. This can give status messages looking
strange, like "X of Y bytes transferred," where X > Y, but that has
more sense than trying to compensate for combinations of data formats
on the server and client when transferring ASCII type data. BTW,
getting the size of a file in advance is unreliable for a number of
reasons in the first place. See question 18.8 of the Infrequently
Asked Questions in comp.lang.c for details.
PR: bin/52072
Tested by: Nick Leuta (earlier versions), a stress-testing tool (final)
MFC after: 1 month
When in inetd mode, this prevents bogus messages from
appearing on the control channel. When running as a
daemon, we shouldn't write to the terminal we used to
have at all.
PR: bin/74823
MFC after: 1 week
Log it once at the beginning of the session instead. OTOH, log wd each
time for the sake of better auditing and consistent log format.
Proposed by: Nick Leuta <skynick -at- mail.sc.ru>
add the working directory pathname to the log message if any of
such arguments isn't absolute. This has advantage over the old
way of logging that an admin can see what users are actually trying
to do, and where. The old code was also not too robust when it
came to a chrooted session and an absolute pathname.
Pointed out by: Nick Leuta
MFC after: 2 weeks
The size_t type is better suited for that, particularly because
the "blksize" argument is to be passed to malloc() and read().
On 64-bit archs it's more to a style issue, but the good style
of coding in C is also important.
Previously logxfer() used to record bogus pathnames to the log
in some cases, namely, when cwd was / or "name" was absolute.
Noticed by: Nick Leuta
MFC after: 2 weeks
that the creation of a PAM context has failed.
N.B. This does not apply to pam_strerror() in RELENG_4, it
will mishandle a NULL "pamh".
Discussed with: des
