userglob [allow|deny]
to
userglob[@host] [allow|deny [classname]]
where class is a userdefined classname.
- if host is given it may either be a CIDR address (e.g, `1.2.3.0/24') or a
hostglob (e.g, `*.foo.com'), and the remote host is matched against that.
- if classname is given, use that to match entries in ftpd.conf (defaults
to `guest' for `anonymous'/`ftp' logins, `chroot' for users found in
/etc/ftpchroot, and `real' for everyone else.
* implement new /etc/ftpd.conf directives:
classtype classname type set type of classname to GUEST, CHROOT, or REAL
motd classname file file to use instead of /etc/motd
rateget classname rate set rateget throttle to rate
rateput classname rate set rateput throttle to rate
upload classname allow/deny uploads (STOU, STOR, APPE). if
denied, also acts as `modify deny'.
* implement new `SITE' commands:
RATEGET as per /etc/ftpd.conf rateget, but cannot exceed that
RATEPUT as per /etc/ftpd.conf rateput, but cannot exceed that
* implement format_file(), which outputs a file to the user, parsing %
escapes. use to print /etc/ftpwelcome, /etc/motd, and the `display' file.
* implement strsuftoi() (from ftp(1)), which parses a number and
optional suffix (for use with rateget, etc)
* don't bother seteuid(0) ; bind(...) ; seteuid(pw->pw_uid), since
we don't need reserved ports (at wasn't getting them anyway).
* update & reorder copyrights
* use strlcpy() as appropriate
the string tokenisation must be performed by the caller (which is
generally easy because it's almost always a static command).
* change do_conversion() to return a char *argv[] instead of char *cmd.
tokenisation of the command is done internally.
* change retrieve() to take char *argv[] instead of char *cmd.
(to take advantage of the above changes). fixes [bin/8173]
* use fparseln() instead of fgetln()
* store conversions in listed order (rather than reverse order)
* use stringlists instead of handrolling code to manage an argv.
connection destination, hoping this to help ftpd's behavior with
scoped IPv6 addresses.
I'm not sure if it is the right way, but it is the best way available to us.
LPRT or EPRT command gives no information about which interface (or scope)
to be used for new data connection.
ftp(1): On data connection establishment, warn if scoped address is used.
If peer (ftp daemon) does not handle scoped address, data connection
may not work right.
This seems to be sort of protocol spec hole, not implementation issue.
is not monotonically increasing (e.g. clock is slaved to another system)
the optimization will result in segments being treated as corrupt
(uncleanable). If enough such "bad" segments were created, the cleaner would
clean continuously, and after some time the system would panic with "no
clean segments".
(Legitimately old partial-segments are relatively rare, and will have their
blocks culled by lfs_bmapv.)
testing and archival for now. I don't expect anyone to work with it
since the binutils and gas changes are still pending. But you got to
crawl before you walk.
lukem