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.
eg:
[foo]
...
matches any executable 'foo'
[/usr/bin/foo/]
...
matches any executable under the directory /usr/bin/foo/
Exact matches continue to function as before.
PR: bin/66769
Submitted-by: Dan Nelson
with the correct alignment. This is important because this calls to
library static constructors are made from here. The bug in the old crt*.s
files hid this because in this case, two wrongs do indeed make a right.
Also, call _rtld_bind() with the correct alignment, because it calls back
into the pthread library locking functions. If things happen just
the wrong way, we get a SIG10 due to the broken stack alignment.
This adds the former ports registered groups: proxy and authpf as well as
the proxy user. Make sure to run mergemaster -p in oder to complete make
installworld without errors.
This also provides the passive OS fingerprints from OpenBSD (pf.os) and an
example pf.conf.
For those who want to go without pf; it provides a NO_PF knob to make.conf.
__FreeBSD_version will be bumped soon to reflect this and to be able to
change ports accordingly.
Approved by: bms(mentor)
that this provokes. "Wherever possible" means "In the kernel OR NOT
C++" (implying C).
There are places where (void *) pointers are not valid, such as for
function pointers, but in the special case of (void *)0, agreement
settles on it being OK.
Most of the fixes were NULL where an integer zero was needed; many
of the fixes were NULL where ascii <nul> ('\0') was needed, and a
few were just "other".
Tested on: i386 sparc64
libexec/ftp-proxy - ftp proxy for pf
sbin/pfctl - equivalent to sbin/ipf
sbin/pflogd - deamon logging packets via if_pflog in pcap format
usr.sbin/authpf - authentification shell to modify pf rulesets
Bring along some altq headers used to satisfy pfctl/authpf compile. This
helps to keep the diff down and will make it easy to have a altq-patchset
use the full powers of pf.
Also make sure that the pf headers are installed.
This does not link anything to the build. There will be a NO_PF switch for
make.conf once pf userland is linked.
Approved by: bms(mentor)
While I'm here, sync the usage() synopsis with the manual page synopsis:
make the [-i | -s] explicit and sort the options alphabetically.
Reminded by: ru
MFC after: 3 days
ever since rev. 1.1 of bootpd.c.
While I'm here, rearrange the synopsis a bit: sort the options and
clarify that -i and -s are mutually exclusive.
Reported by: Atanas Buchvarov <nasko@nove.bg>
MFC after: 3 days
says they may not modify existing files through FTP.
Renaming a file is effectively a way to modify it.
For instance, if a malicious party is unable to delete or overwrite
a sensitive file, they can nevertheless rename it to a hidden name
and then upload a troyan horse under the guise of the old file name.
contents in reply to a RETR command. Such clients consider RETR
as a way to tell a file from a directory. Mozilla is an example.
PR: bin/62232
Submitted by: Bob Finch <bob+freebsd <at> nas <dot> com>
MFC after: 1 week
- Unify the conditional assignments section so that architectural
exclusions come first, then options and !options, sorted by the
option name, also in directory order, then architecture specific
sections, sorted by the architecture name, with i386 being a
traditional exception.
Prodded by: bde
However, the code did allow deletion of files. Make deleting require the -m
flag, too.
PR: bin/60809
Submitted by: Alexander Melkov <melkov@comptek.ru>
constants NG_*SIZ that include the trailing NUL byte. This change
is mostly mechanical except for the replacement of a couple of snprintf()
and sprintf() calls with strlcpy.
(libmap available) and 1 for failure. Assign this return to the
global 'libmap_disable' variable in rtld.c.
This totally prevents any libmap functions from being called after
lm_init() if no config file is present.
Previously, there were two copies of telnet; a non-crypto version
that lived in the usual places, and a crypto version that lived in
crypto/telnet/. The latter was built in a broken manner somewhat akin
to other "contribified" sources. This meant that there were 4 telnets
competing with each other at build time - KerberosIV, Kerberos5,
plain-old-secure and base. KerberosIV is no longer in the running, but
the other three took it in turns to jump all over each other during a
"make buildworld".
As the crypto issue has been clarified, and crypto _calls_ are not
a problem, crypto/telnet has been repo-copied to contrib/telnet,
and with this commit, all telnets are now "contribified". The contrib
path was chosen to not destroy history in the repository, and differs
from other contrib/ entries in that it may be worked on as "normal"
BSD code. There is no dangerous crypto in these sources, only a
very weak system less strong than enigma(1).
Kerberos5 telnet and Secure telnet are now selected by using the usual
macros in /etc/make.conf, and the build process is unsurprising and
less treacherous.
Rationale:
SIGURG is configured by ftpd to interrupt system calls, which is useful
during data transfers. However, SIGURG could interrupt I/O on the
control channel as well, which was mistaken for the end of the session.
A practical example could be aborting the download of a tiny file,
when the abort sequence reached ftpd after ftpd had passed the file
data to the system and returned to its command loop.
Reported by: ceri
MFC after: 1 week
- always check the return value from getc(3) for EOF;
- if the attempt to read the TELNET command byte has
returned EOF, exit from the loop instead of using
the EOF value as a normal character.
MFC after: 1 week
rtld. When _DYNAMIC is referenced normally from C the global offset
table is used implicitly, but newer versions of binutils don't initialize
it statically in the binary, so this doesn't work until rtld is relocated,
which _DYNAMIC is needed for... So, as on other systems with the same
problem, we disassemble a call instruction to _DYNAMIC in order to get
its address.
Setting the LD_DUMP_REL_PRE or LD_DUMP_REL_POST environment variables
cause rtld-elf to output a table of all relocations.
This is useful for debugging.
as the source of defaults for terminal device parameters.
- Do duplucate code reduction and simplification enabled by
the above.
Reviewed by: green
MFC after: 1 month
A PPP login program is started _automatically_ (i.e., without
human intervention) even with the "pl" capability unset, as soon
as a PPP frame is detected. But with "pl" set, a PPP login program
is started independently of the result of PPP detection (which is
rendered unnecessary then,) i.e. _unconditionally_.
don't reveal the info in reply to the SYST command.
Get rid of using the "unix" macro at the same time. It was a rather
poor way to check if the system was Unix since there were quite a
few Unix clones out there whose cc didn't define "unix" (e.g.,
NetBSD.) It was also sensitive to the C standard used, which caused
unnecessary trouble: With -std=c99, it should have been "__unix__",
and so on.
PR: bin/50690
Submitted by: Alex Semenyaka <alexs _at_ snark.ratmir.ru>
MFC after: 1 week
