summaryrefslogtreecommitdiffstats
path: root/libexec/ftpd
Commit message (Collapse)AuthorAgeFilesLines
* Add some consistency checks to the signal-related code.yar2005-02-161-0/+6
| | | | MFC: along with rev. 1.202
* A call to maskurg() makes sense only when a transfer is under way,yar2005-02-161-3/+5
| | | | | | | the function will emit an annoying log message otherwise. Reported by: kris MFC: along with rev. 1.202
* Fix most cases where the address of an int is passed to a function expecting astefanf2005-02-141-5/+8
| | | | socklen_t * argument.
* Respect the `logging' flag.yar2005-01-191-1/+1
| | | | | Pointed out by: Nick Leuta MFC after: 3 days
* Improve handling SIGURG and OOB commands on the control channel.yar2005-01-191-134/+269
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Sort sections.ru2005-01-181-6/+6
|
* Replace err(3) calls when in daemon mode by syslog(3), too.yar2005-01-101-4/+8
| | | | | | | A daemon has no stderr to send its complains to. Pointed out by: Nick Leuta MFC after: 1 week
* NOPAM -> NO_PAMru2004-12-211-1/+1
|
* Do a small style(9) fix before I'm hacking the code itself.yar2004-12-161-1/+0
|
* free(3) is void already.yar2004-12-161-1/+1
|
* Never emit a message to stderr: use syslog instead.yar2004-12-121-9/+15
| | | | | | | | | | 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
* When looking for a virtual host to handle the connection,yar2004-11-221-2/+3
| | | | | | stop the search on the first match for efficiency. Submitted by: Nick Leuta
* Calling pam_chauthtok() isn't really needed sinceyar2004-11-221-7/+3
| | | | | | an FTP user has no chance to change password anyway. Submitted by: Nick Leuta
* Don't log the chroot dir on every command since it's constant for a session.yar2004-11-221-9/+8
| | | | | | | 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>
* Always log remote IP.yar2004-11-221-13/+9
| | | | PR: bin/59773
* Treat host name buffers consistently.yar2004-11-221-12/+23
|
* Make chrootdir global and use it in log messagesyar2004-11-181-9/+4
| | | | | | regarding restricted users. MFC after: 2 weeks
* Nitpicking on style(9) and whitespace.yar2004-11-181-13/+13
| | | | Tested with: md5(1)
* Use __FBSDID.yar2004-11-184-8/+12
|
* Don't say, "file: permission denied," if the operationyar2004-11-181-1/+1
| | | | is disabled entirely.
* Use uniform punctuation, capitalization, and language styleyar2004-11-182-45/+44
| | | | | in server messages wherever this doesn't contradict to a particular message format.
* Apply __printflike() to the appendf() prototype so the compileryar2004-11-181-1/+1
| | | | can detect format errors.
* Fix perror_reply() vs. reply() usage.yar2004-11-182-3/+3
|
* '\n' needs not to appear in reply() strings.yar2004-11-181-3/+3
|
* Log pathname arguments to ftp commands as the user specified them;yar2004-11-181-33/+55
| | | | | | | | | | | 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
* Use S_ISDIR() macro instead of a hand-rolled test.yar2004-11-181-1/+1
|
* getcwd() won't leave a error string in the buffer, unlike getwd().yar2004-11-181-1/+1
|
* Use POSIX functions instead of legacy ones:yar2004-11-171-2/+2
| | | | | getwd() -> getcwd() wait3() -> waitpid()
* Kill more unneeded casts found.yar2004-11-172-4/+4
| | | | Noticed by: Nick Leuta <skynick -at- mail.sc.ru> (some of them)
* Don't invent ways of capitalization orthogonal to the English grammar.yar2004-11-151-2/+2
|
* RFC 959 states that the following codes should be usedyar2004-11-151-3/+5
| | | | | | | | | | for status replies on file system objects: 212 Directory status. 213 File status. Reported by: Oleg Koreshkov <okor -at- zone.salut.ru> MFC after: 1 week
* Using off_t to pass a block size is obvious overkill.yar2004-11-131-2/+2
| | | | | | | 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.
* Kill ancient casts to integral types left from the K&R era.yar2004-11-133-9/+9
| | | | They're unneeded and sometimes erroneous now.
* Fix logxfer() by using realpath(3) instead of playing with getwd(3).yar2004-11-031-4/+8
| | | | | | | | 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
* Replace the last occurence of (long long) and %qd withyar2004-11-021-2/+2
| | | | | | | (intmax_t) and %jd, which is the right way to printf an off_t in the presence of <stdint.h>. Submitted by: Nick Leuta
* OpenPAM allows passing a NULL "pamh" to pam_strerror() to indicateyar2004-11-011-2/+5
| | | | | | | | | 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
* - Stop shadowing global "pamh" by a local variable in auth_pam().yar2004-10-301-9/+15
| | | | | | | | | - Stop calling pam_strerror() with NULL pamh. - Add a missing call to pam_end(). PR: bin/59776 Submitted by: Nick Leuta <see PR for email> MFC after: 2 weeks
* Describe the semantics of the sgetpwnam() helper functionyar2004-10-301-0/+3
| | | | | in the comment above it so that nobody will save pointers returned inside "struct passwd" across the calls to the function.
* Log the actual number of bytes sent on the wire to /var/log/ftpdyar2004-10-241-2/+2
| | | | | | | | | | 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
* We must not fall back to the old way (read-write)yar2004-10-151-1/+1
| | | | | | | | 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
* Clean-up around sendfile(): drop an excessive check for error condition.yar2004-10-151-2/+2
|
* Account for the fact that sendfile(2) may hit the end of fileyar2004-10-151-1/+12
| | | | | | | | prematurely, e.g., if the file has been truncated by someone else. PR: bin/72649 Submitted by: Oleg Koreshkov (portions) MFC after: 2 weeks
* Indent.maxim2004-09-241-7/+7
|
* o Merge rev. 1.5 libexec/ftpd/ftpd.c from DragonflyBSD:maxim2004-09-241-0/+2
| | | | | | | | | | | | 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
* ftpd(8) seems to be WARNS=2 clean now.yar2004-07-311-0/+1
| | | | Tested on: i386, ia64, amd64, sparc64, alpha
* Change ``(foo *)0'' to ``NULL'' where it's possibleyar2004-07-312-11/+11
| | | | | | | (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.
* Kill a small herd of casts to off_t where they were not needed.yar2004-07-312-10/+9
| | | | | | Thank Fortune, the C compiler can figure out by itself the proper conversion for assignments, comparisons, and prototyped function arguments.
* Printf(3) off_t values through conversion to intmax_t sinceyar2004-07-312-10/+15
| | | | we've got <stdint.h> et al now. (This makes ftpd(8) WARNS=2 clean.)
* Kill an unused variable (heading to WARNS=2.)yar2004-07-311-1/+0
|
* Convert a couple of bogus null statements to the right form.yar2004-07-311-2/+2
| | | | (Heading to WARNS=2.)
OpenPOWER on IntegriCloud