Replacing the Mac OS X FTP Server

   

---

If you decide to activate anonymous FTP, especially anonymous FTP with an upload directory, you should consider replacing the default ftpd with a more modifiable ftpd . A popular, highly configurable replacement ftpd is wu-ftpd , available at http://www.wu-ftpd.org/. In addition to being highly configurable, it easily compiles under Mac OS X.

Although popular and highly configurable, wu-ftpd is not exempt from security problems. It's still important to regularly monitor the anonymous FTP area, if you have one, as well as make sure that you have the latest version of wu-ftpd , which is version 2.6.2 as of this writing.

Installing wu-ftpd

To replace the default ftpd with wu-ftpd , first download, compile, and install wu-ftpd . Fortunately, wu-ftpd is one of the packages that follows this basic format for compilation and installation:

 ./configure make make install 

When you download the wu-ftpd source files, also download any patches available for the source. As of this writing, the current version, 2.6.2, doesn't have any patches. However, because updates to wu-ftpd are frequently available as patches, we include a demonstration of using patch to apply a patch to the previous version, 2.6.1. After a patch file is copied to the root directory of the source, run patch as follows:

 [localhost:~/wu-ftpd-2.6.1] software% patch -p0 < missing_format_strings.patch 

The default config.guess and config.sub files that come with the wu-ftpd source don't work with Mac OS X. Use the files that come with Mac OS X:

 [Sage-Rays-Computer:~/src/wu-ftpd-2.6.2] software%  cp   /usr/share/automake-1.6/config.guess ./  [Sage-Rays-Computer:~/src/wu-ftpd-2.6.2] software%  cp   /usr/share/automake-1.6/config.sub ./  

If you haven't already done so, create a bin user . The bin user is needed for wu-ftpd to install properly. The bin user should have a relatively low uid . Mac OS X already comes with a bin group with gid 7 . In many other Unix variants, the bin user has the same uid and gid . As with the ftp user, follow the basic parameters of a generic user, such as the unknown user. You might consider duplicating the unknown user and editing values. Suggested values for the bin user are shown in Table 12.5.

Table 12.5. Suggested Parameters for a bin User

Property	Value
name	bin
realname	System Tools Owner
uid	7
passwd	*
home	/bin
shell	/bin/sync
gid	7
change
expire

Next , you're ready to run ./configure . Being the highly configurable package that it is, you can pass many parameters to configure , as detailed in Table 12.6. Consider the basic design of FTP as you look at the available options and you will see that the server built can range from one that is quite tightly controlled to one that could not be considered secure by even the wildest stretch of the imagination . The power and customizability available to you in the running server spans a similarly large range, depending on the options chosen here. Therefore, building a server that allows you the power and flexibility you need, while not providing too many opportunities for security problems requires careful study.

TIP

To have an ls that works properly under version 10.2 for anonymous FTP or guest FTP, you may need to use the --enable-ls option.

Table 12.6. Configure Options for wuftpd

Option	Description
--with-etc-dir= PATH	Path for configuration files, usually /etc .
--with-pid-dir=PATH	Path for run/pid files, usually.
--with-log-dir=PATH	Path for log files ( xferlog ), usually /var/log .
--disable-upload	Disables support for the upload keyword in the ftpaccess file.
--disable-overwrite	Disables support for the overwrite keyword in the ftpaccess file.
--disable-hostxs	Disables support for the allow and deny keywords in the ftpaccess file.
--disable-logfailed	Disables logging of failed attempts (wrong password, wrong username, and so on).
--disable-logtoomany	Disables logging of failed attempts that failed because too many users were already logged in.
--disable-private	Disables support for private files ( site group/site gpass FTP commands).
--disable-dnsretry	Disables retrying failed DNS lookups at connection time.
--enable-anononly	Allows only anonymous FTP connections.
--enable- paranoid	Disables some features that might possibly affect security.
--disable-quota	Disables support of disk quotas, even if your operating system is set for them.
--disable-pam	Does not use PAM authentication, even if your operating system supports it.
--enable-skey	Supports S/Key authentication (needs S/Key libraries).
--enable-OPIE	Supports OPIE (One Password In Everything) authentication (needs OPIE libraries).
--disable-new-cd	Causes cd ~ to not return to the chroot -relative home directory.
--enable-chmod	Allows FTP users to set SETUID , SETGID , and STICKY bits on file permissions.
--disable-rfc931	Does not do RFC931 ( IDENT ) lookups ( worse logging, but faster).
--disable-daemon	Does not support running as a normal daemon (as opposed to running from inetd ).
--disable-map-chdir	Does not keep track of user's path changes. This leads to worse symlink handling.
--disable-throughput	Does not keep track of user's throughput.
--disable-count	Does not keep track of transferred bytes (for statistics).
--disable-newlines	Suppresses some extra blank lines.
--enable-crackers	Does not wait for password entry if someone tries to log in with a wrong username. Although convenient , it is a security risk in that crackers can find out names of valid users.
--disable-verbose	Disables verbose error logging.
--enable-NOOP	NOOP command resets idle time.
--disable-log-rp	Logs the relative path rather than the real path.
--disable-virtual	Disables support of virtual servers.
--disable-closedvirt	Allows guests to log in to virtual servers.
--disable-dns	Skips all DNS lookups.
--disable-port	Disallows port-mode connections.
--disable-pasv	Disallows passive-mode connections.
--disable-plsm	Disables PID lock sleep messages. Recommended for busy sites.
--disable-pasvip	Does not require the same IP for control and data connection in passive mode. This is more secure, but can cause trouble with some firewalls.
--disable-anonymous	Allows only real users to connect.
--enable-ls	Uses the internal ls command instead of /bin/ls in the chroot directory. This is experimental and has known problems.
--enable-numericuid	Makes the internal ls display UID and GID instead of user / group names. This is faster, but the ls output looks worse.
--disable-hidesetuid	Causes the internal ls command to not hide setuid / setgid bits from the user. Default is for the internal ls to hide them as a security precaution.
--disable-mail	Disables support of the mail-on-upload feature. The feature allows you to automatically send an email message to the FTP administrator whenever an anonymous user uploads a file.
--enable-badclients	Supports broken clients . See the CHANGES file for details.
--with-bufsize=x	Sets the buffer size to x . (You won't usually have to adjust this value.)
--with-backlog=x	Sets the number of incoming processes to backlog in daemon mode to x . Default is 100.

To distinctly separate the wu-ftpd installation from the default ftpd , you should consider specifying paths in the various path parameters. In addition, you might consider running ./configure with -prefix= <some-directory-for-wu-ftpd> so that the wu-ftpd binaries and man pages are all in one place. You might also find it interesting that you can create either an anonymous-only or a real users-only FTP server. Next, run make and make install .

After you have a wu-ftpd binary, you should update the /etc/xinetd.d/ftp file to reflect the location of the new ftpd , as well as any runtime options that should be used. After you've adjusted /etc/xinetd.d/ftp , have xinetd reread its configuration file. Runtime options available in wu-ftpd are detailed in Table 12.7. Like the compile-time options, careless choices can open holes in your system that may come back to haunt you later. Think through what options you need and test your configuration carefully . As we've previously suggested, it's best to err on the side of caution in your configuration choices, and not enable "interesting" features just because they're interesting. Wait until you actually have a need for a feature before you add that capability to your option collection.

Table 12.7. Runtime Options for wuftpd

Option	Function
-d	Logs debugging information to the syslog .
-v	Logs debugging information to the syslog .
-l	Logs each FTP session to the syslog .
-t <timeout>	Sets the inactivity timeout period to <timeout> seconds. Default is 15 minutes.
-T <maxtimeout>	A client may also request a different timeout period. The maximum period may be set to <timeout> seconds. Default is 2 hours.
-a	Enables the use of the ftpaccess(5) configuration file.
-a	Disables the use of the ftpaccess(5) configuration file. This is the default.
-l	Logs commands sent to the ftpd server to the syslog . Overridden by the use of the ftpaccess file. With the L command, logging occurs as soon as the FTP server is invoked. All USER commands are logged. If a user accidentally enters a password for a username, the password is logged. Unless you're actively trying to debug a problem or an attack, enabling this is probably a bad idea.
-i	Logs files received by the ftpd server to the xferlog(5) . Overridden by the use of the ftpaccess(5) file.
-i	Disables use of RFC931 ( AUTH / ident ) to attempt to determine the username on the client.
-o	Logs files transmitted by the ftpd server to the xferlog(5) . Overridden by the use of the ftpaccess(5) file.
-p <ctrlport> -P <dataport>	Overrides port numbers used by the daemon. Normally the port number is determined by the ftp and ftp-services values in services . If there is no entry for ftp-data and -P is not specified, the daemon uses the port just prior to the control connection port. The -p option is available only for the standalone daemon.
-q -q	Determines whether the daemon uses the PID files, which are required by the limit directive to determine the number of current users in each access class. Disabling the use of PID files disables user limits. Default, -q , is to use PID files. Specify -Q as a normal user testing the server when access permissions prevent the use of PID files. Large, busy sites that do not want to impose a limit on the number of concurrent users might consider disabling PID files.
-r <rootdir>	Instructs the daemon to chroot(2) to <rootdir> immediately upon loading. This can improve system security by limiting the files that can be damaged in a break-in. Setup is much like anonymous FTP, with additional files required.
-s -s	Sets the daemon to standalone mode. The -S option runs the daemon in the background and is useful in startup scripts during system initialization (that is, rc.local ). The -s option leaves the daemon in the foreground and is useful when running from init (that is, /etc/inittab ).
-u <umask>	Sets the default umask to <umask>.
-v	Displays the copyright and version information, then terminates.
-w	Records every login and logout. Default.
-w	Does not record user logins in the wtmp file.
-X	Does not save output created by -i or -o to the xferlog file, but saves it via syslog so that output from several hosts can be collected on one central loghost .

Limiting Access

Access to wu-ftpd can be limited through the use of the ftpusers , ftphosts , and ftpaccess files.

ftpusers

Like the default ftpd , wu-ftpd also uses an ftpusers file as a way of restricting access on a per-user basis. Copy the default /etc/ftpusers file to the etc directory of your wu-ftpd installation and add any users who should not be granted FTP access.

ftphosts

The ftphosts file is used to allow or deny access on a user/host basis. The basic syntax of a rule is as follows:

 allow <username> <addrglob> [<addrglob> ...] deny <username> <addrglob> [<addrglob> ...] 

The <addrglob> may be a specific hostname, IP address, or pattern of each. Additionally, <addrglob> may also be specified as address/cidr or address: netmask . As you may expect, the order of the allow and deny rules can be important; the rules are processed sequentially on a first-match-wins basis. When you create these rules, be sure to think about rule order, particularly with any allow and deny pairs.

For example, to grant user marvin access from only marvin.biosci.ohio-state.edu , but not any other machines on the biosci.ohio-state.edu network, use this set of rules:

 allow marvin marvin.biosci.ohio-state.edu deny marvin *.biosci.ohio-state.edu 

If the rules were reversed , then wu-ftpd would encounter the deny rule first, which would deny access to user marvin from all biosci.ohio-state.edu machines, including marvin.biosci.ohio-state.edu .

ftpaccess

Although wu-ftpd provides a lot of configuration options with its compile-time and runtime options, more controls can be set in the ftpaccess file. To enable the use of the ftpaccess file, be sure to run wu-ftpd with the -a option.

Selected useful controls in ftpaccess are documented in Table 12.8. Be sure to read the ftpaccess man page thoroughly for information about these and other available controls.

Table 12.8. Selected Controls Available for ftpaccess

Control	Function
loginfails <number>	Logs a "repeated login failures" message after <number> login failures. Default is 5.
class <class> <typelist> <address> [<address>...]	Sets up classes of users and valid access addresses. <typelist> is a comma-separated list of any of these keywords: real , anonymous , or guest . If real is included, the class can include users FTPing to real accounts. If anonymous is included, the class can include anonymous FTP users. If guest is included, the class can include members of guest access accounts.
guestgroup <groupname> [<groupname>...]	For guestgroup , if a real user is a member of any specified <groupname> , the session is set up exactly as with anonymous FTP. In other words, a chroot is done and the user is no longer permitted to issue the USER and PASS commands. <groupname> is a valid group from NetInfo. In other words, a real user whose group is <groupname> is treated as a guest FTP user. A guest user's home directory must be properly set up, exactly as anonymous FTP would be. The group name may be specified by either name or numeric ID. To use a numeric group ID, place a % before the number. Ranges may be given. Use an asterisk to mean all groups.
guestuser <username> [<username> ...]	guestuser works like guestgroup , except it uses the username (or numeric ID).
realgroup <groupname> [<groupname> ...] realuser <username> [<username> ...]	realuser and realgroup have the same syntax, but reverse the effect of guestuser and guestgroup . They allow real user access when the remote user would otherwise be determined a guest.
limit <class> <number> <times> <message_file>	Limits the number of users belonging to <class> to access the server during the <times> indicated and posts <message_file> as the reason for access denial.
file-limit [<raw>] <in out total> <count> [<class>]	Limits the number of files a user in <class> may transfer. Limit may be placed on files in, out, or total. If no class is specified, the limit is the default for classes that do not have a limit specified. <raw> applies the limit to the total traffic rather than just data files.
data-limit [<raw>] <in out total> <count> [<class>]	Limits the number of data bytes a user in <class> may transfer. Limit may be placed on bytes in, out, or total. If no class is specified, the limit is the default for classes that do not have a limit specified. <raw> applies the limit to the total traffic rather than just data files.
limit-time {* anonymous guest} <minutes>	Limits the total time a session can take. By default, there is no limit. Real users are never limited.
log commands <typelist>	Logs individual commands issued by users in <typelist> , where <typelist> is a comma-separated list of any of the keywords real , anonymous , or guest .
log transfers <typelist> <directions>	Logs the transfers of users belonging to <typelist> in the specified <directions> . <typelist> is a comma-separated list of any of the keywords real , anonymous , or guest . <directions> is a comma-separated list of the keywords inbound or outbound , where inbound refers to transfers to the server and outbound refers to transfers from the server.
log syslog	Redirects logging messages for incoming and outgoing transfers to the system log. Default is xferlog .
log syslog+xferlog	Logs transfer messages to both the system log and xferlog .
defaultserver deny <username> [<username>...] defaultserver allow <username> [<username>...]	By default all users are allowed access to the default, nonvirtual FTP server. defaultserver <deny> denies access to specific users. You could use defaultserver <deny> * to deny access to all users, then defaultserver <allow> to allow specific users.
guestserver [<hostname>]	Controls which hosts may be used for anonymous or guest access. If used without <hostname> , denies all guest or anonymous access to this site. More than one <hostname> may be specified. Guest and anonymous access are allowed only on the named machines. If access is denied , the user is asked to use the first <hostname> listed.
passwd-check <level> <enforcement>	Defines the level and enforcement of password checking done by the server for anonymous FTP. <level> can be none , trivial (must contain an @ ), or rfc822 (must be an RFC822-compliant address). <enforcement> can be warn (warns the user but allows him to log in) or enforce (warns the user and logs him out).
chmod <yes no> <typelist> delete <yes no> <typelist> overwrite <yes no> <typelist> rename <yes no> <typelist> umask <yes no> <typelist>	Sets permissions for chmod , delete , overwrite , rename , and umask as yes or no for users in <typelist> , where <typelist> is a comma-separated list of any of the keywords real , anonymous , or guest .
upload [absolute relative] [class=<classname>]... [-] <root-dir> <dirglob> <yes no> <owner> <group> <mode> [dirs nodirs] [<d_mode>]	Specifies upload directory information. <root-dir> specifies the FTP root directory. <dirglob> specifies a directory under the <root-dir> . <yes no> indicates whether files can be uploaded to the specified directory. If yes , files will be uploaded as belonging to <owner> and <group> in <mode> . [dirs nodirs] specifies whether or not new subdirectories can be created in the upload directory. If dirs , they are created with mode <d_mode> , if it is specified. Otherwise, they are created as defined by <mode> . If <mode> is not specified, they are created with mode 777 . Upload restrictions can be specified by class with class=<classname> .
path-filter <typelist> <mesg> <allowed_charset> [< disallowed regexp>...]	Defines regular expressions that control what a filename can or cannot be for users in <typelist> , where <typelist> is a comma-separated list of any of the keywords real , anonymous , or guest .
noretrieve [absoluterelative] [class=<classname>]... [-] <filename> <filename>...	Always denies the ability to retrieve these files. If the files are a path specification (begin with a / character), only those files are marked irretrievable. Otherwise, all files matching the filename are refused transfer. For example: noretrieve /etc/passwd core specifies no one can get the file /etc/passwd , but users will be allowed to transfer a file called passwd if it is not in /etc . On the other hand, no one can get files named core , wherever they are. Directory specifications mark all files and subdirectories in the named directory irretrievable. The <filename> may be specified as a file glob. For example: noretrieve /etc /home/*/.htaccess specifies no files in /etc or any of its subdirectories may be retrieved. Also, no files named .htaccess anywhere under the /home directory may be retrieved. The optional first parameter selects whether names are interpreted as absolute or relative to the current chroot ed environment. The default is to interpret names beginning with a slash as absolute. The noretrieve restrictions may be placed on members of particular classes. If any class= is specified, the named files are not retrievable only if the current user is a member of any of the given classes.
throughput <root-dir> <subdir-glob> <file-glob-list> <bytes-per-second> <bytes-per-second-multiply> <remote-glob-list>	Restricts throughput to <bytes-per-second> on download of files in the comma-separated <file-glob-list> in the subdirectory matched by <subdir-glob> under <root-dir> when the remote host or IP address matches the comma-separated <remote-glob-list> .
anonymous-root <root-dir> [<class>]	Specifies <root-dir> as the chroot path for anonymous users. If no anonymous-root is matched, the old method of parsing the home directory for the FTP user is used.
guest-root <root-dir> [<uid-range>]	Specifies <root-dir> as the chroot path for guest users. If no guest-root is matched, the old method of parsing the user's home directory is used.
deny-uid <uid-range> [...] deny-gid <gid-range> [...] allow-uid <uid-range> [...] allow-gid <gid-range> [...]	The deny clauses specify UID and GID ranges that are denied access to the FTP server. The allow clauses are then used to allow access to those who would otherwise be denied access. deny is checked before allow . Default is to allow access. Use of these controls can remove the need for the /etc/ftpusers file. Wherever uid or gid can be specified in the ftpaccess file, either names or numbers may be used. Put % before numeric uid or gid .
restricted-uid <uid-range> [...] restricted-gid <gid-range> [...] unrestricted-uid <uid-range> [...] unrestricted-gid <gid-range> [...]	Controls whether or not real or guest users are allowed access to areas on the FTP server outside their home directories. Not intended to replace the use of guestgroup and guestuser . The unrestricted clauses may be used to allow users outside their directories when they would have been otherwise restricted.
passive ports <cidr> <min> <max>	Allows control of the TCP port numbers that may be used for a passive data connection. If the control connection matches <cidr> , a port in the <min> to <max> range is randomly selected for the daemon to listen on. This control allows firewalls to limit the ports that remote clients use for connecting to the protected network. <cidr> is shorthand for an IP address in dotted -quad notation, followed by a slash and the number of leftmost bits that represent the network address. For example, for the reserved class-A network 10 , instead of using a netmask of 255.0.0.0 , use a CIDR of 8 , and 10.0.0.0/8 represents the network. Likewise, for a private class-C home network, you could use 192.168.1.0/24 to represent your network.
deny <addrglob> <message_file>	Always denies access to host(s) matching <addrglob> and displays <message_file> to the host(s). <addrglob> may be !nameserved to deny access to sites without a working nameserver. It may also be the name of a file, starting with a slash ( / ), which contains additional address globs , as well as in the form <address>:<netmask> or <address>/<cidr> .
dns refuse_mismatch <filename> [override]	Refuses FTP sessions when the forward and reverse lookups for the remote site do not match. Displays <filename> to warn the user. If override is specified, allows the connection after complaining.
dns refuse_no_reverse <filename> [override]	Refuses FTP sessions when there is no reverse DNS entry for the remote site. Displays <message> to warn the user. If override is specified, allows the connection after complaining.

Understanding Basic ftpaccess Controls

As you saw in Table 12.8, even a selective list of ftpaccess controls is large. Because many controls are available, let's take a look at some of the basic configuration controls in the ftpaccess file.

class

Look at this statement:

 class   staff   real    *.biosci.ohio-state.edu 

In this example, a class called staff is defined as being a real user coming from anywhere in the biosci.ohio-state.edu domain.

In the following statement, a class called local is defined as being as guest user coming from anywhere in the ohio-state.edu domain:

 class   local   guest   *.ohio-state.edu 

In the following statement, a class called remote is defined as being an anonymous user whose connection comes from anywhere:

 class   remote  anonymous       * 

You can create as many classes as suit your needs.

limit

In the following statement, there is a limit of five users belonging to class remote who can access the FTP server on Saturdays and Sundays and on any day between 6:00 p.m. and 6:00 a.m.:

 limit   remote  5       SaSuAny1800-0600       /usr/local/etc/msgs/msg.toomany 

When the limit is reached, any additional user sees a posting of the message file, msg.toomany , in /usr/local/etc/msgs .

In the following statement, no users belonging to the class staff can access the FTP server at any time:

 limit   staff  0       Any             /usr/local/etc/msgs/msg.notallowed 

Whenever any user in class staff attempts to log in, she sees a message indicating that she is not allowed to access the FTP server.

upload

In the following statements, the guest user, bioftp , can upload files to the ~ftp/public directory. The files will be uploaded with permissions 600 , that is, read and write permissions, for guest user bioftp :

 upload  /home/ftp   /public       yes     bioftp   ftponly      0600 upload  /home/ftp   /public/*     yes     bioftp   ftponly      0600 

However, in the following statement, no user can upload to the ~ftp/bin directory:

 upload  /home/ftp   /bin          no 

Please note that the upload control also has a nodirs option that does not allow directories to be uploaded. If you decide to run an anonymous FTP server, make sure that you include the nodirs option to the upload control.

restricted-uid and restricted-gid

Although restricted-uid and restricted-gid are straightforward controls, it is useful to note that these controls function like the /etc/ ftpchroot file for the default ftpd .

A restricted control entry such as this:

 restricted-uid marvin 

restricts user marvin to his home directory for FTP access. The numeric uid for marvin , preceded by % , could be used instead, as well as a range of uid s.

Controlling Bandwidth and Other Advanced Features

The controls available in ftpaccess range from basic controls to advanced controls. With the advanced features, you can control many aspects of an FTP session. Some of the interesting controls include limiting the throughput, limiting the number of bytes that can be transferred, limiting the number of files that can be transferred, refusing sessions from hosts whose forward and reverse name lookups don't match or if a DNS lookup can't be done, and specifying a passive port range for a passive data connection.

throughput

The throughput directive is one that you can use to help make your anonymous FTP site less attractive. Here is a sample throughput directive:

 throughput /Users/ftp /pub*  *zip   22000  0.5  * 

The example statement limits the throughput of a zip file downloaded from the pub directory to approximately 22000 bytes/second from any remote host. Furthermore, because a multiply factor of 0.5 is also specified, the second zip file is downloaded at a rate of approximately 11000 bytes/second; the third, 5500 bytes/second, and so on.

file-limit

The number of files uploaded, downloaded, or transferred in total by a user in a given class can be restricted with the file-limit directive. For example,

 file-limit in 1 remote 

limits the number of files uploaded to your site by a user belonging to class remote to just one file.

data-limit

Use the data-limit directive to limit the number of data bytes that can be uploaded, downloaded, or transferred in total by a user in a given class. In this statement

 data-limit total 5000000 remote 

the total number of data bytes that may be transferred by a user in class remote is restricted to approximately 5000000 bytes.

dns refuse_mismatch

To deny access to a host whose forward and reverse DNS lookups don't match, use the dns refuse_mismatch directive. In this example

 dns refuse_mismatch mismatch-warning override 

the file, mismatch-warning , is displayed for the offending host, but with the override option in place, the host is granted access anyway.

dns refuse_no_reverse

To deny access to a host for which a reverse DNS lookup can't be done, use the dns refuse_no_reverse directive. In this statement

 dns refuse_no_reverse noreverse-warning 

the file named noreverse-warning is displayed, and the connection from the offending host is refused.

passive ports

At this time, the passive ports directive may not seem important. However, if you decide to use the built-in firewall package, ipfw , you may find the passive ports directive useful for allowing passive connections through your firewall. In this example,

 passive ports 140.254.12.0/24 15001 19999 

ports in the range of 15001 to 19999 for passive data connections from 140.254.12.* have been specified. This directive could be used in conjunction with an ipfw rule to permit a passive data connection through the firewall.

Understanding the xferlog

By default, wu-ftpd logs transfer to a file called xferlog . Each entry in the log consists of an entry in this format:

 <current-time> <transfer-time> <remote-host> <file-size> <filename> <transfer-type> <special-action-flag> <direction> <access-mode> <username> <service-name> <authentication-method> <authenticated-user-id> <completion-status> 

At a casual glance, that format may seem a bit overwhelming. Let's look at some sample entries to better understand that format.

Here is an entry resulting from someone contacting the anonymous FTP server:

[View full width]

 
 [View full width] 
 Fri May 11 13:32:19 2001 1 calvin.biosci.ohio-state.edu 46 /Users/ftp/incoming/file4 b _  i a joray@ ftp 0 * c 

Immediately apparent are the date and time when the transfer occurred. The next entry, the 1 , indicates that the transfer time was only 1 second. The remote host was calvin.biosci.ohio-state.edu . The file size was 46 bytes. The file transferred was file4 in the incoming area of the anonymous FTP server. The transfer was a binary transfer. No special action, such as compressing or tarring, was done. From the i , you can see that this was an incoming transfer; that is, an upload. From the a , you can see that this was an anonymous user. The string identifying the username in this case is joray@ . That is the password that the user entered. The ftp indicates that the ftp service was used. The indicates that no authentication method was used. The * indicates that an authenticated user ID is not available. The c indicates that the transfer completed.

Here is an entry resulting from a guest user contacting the FTP server:

[View full width]

 
 [View full width] 
 Fri May 11 16:32:24 2001 5 calvin.biosci.ohio-state.edu 5470431 /Users/guests/betty/  dotpaper.pdf b _ i g betty ftp 0 * c 

It looks much like the anonymous entry. In this entry, the transfer time was 5 seconds. The file transfer was larger than in the previous example, 5470431 bytes. The i indicates that this transfer was also an incoming transfer, an upload. The g indicates that the user involved was a guest user. The guest user was user betty.

Here is an entry resulting from a real user contacting the FTP server:

[View full width]

 
 [View full width] 
 Fri May 11 15:34:14 2001 1 ryoohki.biosci.ohio-state.edu 277838 /Users/marvin/  introduction.ps b _ o r marvin ftp 0 * c 

Again, this entry is much like the other two entries you have seen. In this example, you can learn from the o that the transfer was an outgoing transfer; that is, a download. The r indicates that a real user made the transfer. In this case, the real user was marvin.

Guest User Accounts

As you've seen, wu-ftpd understands three types of users: real, anonymous, and guest. Real users are users who have full login access to your machine. You can restrict your real users' FTP access to their home directories, if you so choose. Whether you choose to do so is up to you. If you trust your users enough to give them full login access to your machine in the first place, you might also trust them with full FTP access. Anonymous users are users who have access to only the anonymous area of your machine, if you chose to create an anonymous FTP area. Guest users are users who have accounts on your machine, but aren't granted full access to your machine. Guest user accounts might be suitable for users who have Web sites on your machine and need FTP access only to occasionally update their Web sites.

A guest user account is a cross between a real user account and an anonymous FTP account. A guest user has a username and password, but doesn't have shell access to his account. This allows him to use FTP to access files on the server via a user ID and password, but prevents him from being able to log in to the machine either through the network or at the console. Guest user accounts are useful if, for example, you need to set up a place where a group of collaborators can share sensitive information and data, but where you don't really want members of the group to be full users of your machine. If you set up a single guest user account for this group of users, they can all access it with a user ID and password, and people without the user ID and password can't, so their information remains private. Because they don't have real shells , however, they can't log in to your machine and use any resources other than those that are available through the FTP server.

Guest user accounts are set up similarly to the anonymous FTP account. The users are restricted to their home directories only, as is the anonymous FTP account, and their accounts contain the commands that they might need to run while accessing their accounts via FTP.

If you decide that you need guest user accounts, do the following to implement a guest user:

1. Decide where the guest user's home directory should be. You could put your guest users in the same location as your regular users. You also could create a directory somewhere for guest users and place guest user directories in that location.

2. After you've decided where the guest account should reside, make a guest account. You could create your user in the Accounts pane in System Preferences. Your guest user, however, might not really have a need for all the directories that are made in a user account created in this way. You can decide what directories might be necessary. If you anticipate having many guest users, you could create a guest skeleton user as your basis for guest accounts.

3. The guest user should belong to some sort of guest group. Create a guest group with an unused GID number. Edit the guest user's account to belong to the guest group. The guest user's shell should be modified to some nonexistent shell. Make sure that the guest user's home directory and everything in it are owned by the guest user with the guest group.

4. There are two possible ways to list the guest user's home directory. The traditional way is to include a . where the FTP server should chroot to as the root FTP directory. For example, you could create a guest user called betty , with a home directory located in /Users/guests/betty/ . To indicate that the root directory that you want betty to see when she accesses the FTP server to be /Users/guests/betty/ , you would edit the home directory to be /Users/guests/betty/./ . If you wanted betty to be able to see a listing of other guest users' directories before changing to her directory, you could list her home directory as /Users/guests/./betty . With her home directory listed this way, her guest root directory does not need to be specifically listed in the ftpaccess file. Figure 12.3 shows how the guest user's home directory appears in NetInfo Manager when indicated by this method.

   Figure 12.3. Here are the parameters used for the guest user betty . Her home directory is listed in the traditional notation for a guest user, which includes a . to indicate the root directory that the user sees when she FTPs.

   

   The other way to list a guest user's home directory is to list the home directory as usual in NetInfo Manager. In the ftpaccess file, list the guest user's root directory with the guestuser control. The user's directory in the NetInfo database then looks like the notation for any real user's home directory, as you can see for guest user ralph in Figure 12.4.

   Figure 12.4. The home directory for this guest user is indicated in the regular fashion. The root directory for FTP for this guest user is indicated instead by the use of the guestuser control in the ftpaccess file.

   

   The entry for the guest user's root directory in ftpaccess looks like this:

    guestuser ralph 

5. Include the shell that you use for the guest in /etc/shells . You might want the contents of your fake guest user shell to be something like this:

    #! /bin/sh exit 1 

6. Update the ownership information of the guest user's account to include the guest group GID that is indicated in the NetInfo database.

7. Copy the same system files that are used for the anonymous FTP user to the guest user's account. Specifically, make sure the system's

    /bin/ls /usr/lib/dylib /usr/lib/libSystem.B.dylib /System/Library/Frameworks/System.framework/Versions/B/System 

   are included in the guest user's home directory. In this example, for user ralph , the files would be placed in /Users/guests/ralph/bin/ , /Users/guests/ralph/usr/lib/ , and /Users/guests/ralph/System/Library/Frameworks/System.framework/Versions/B/ with the same permissions and ownerships that are used for an anonymous FTP account.

   If you create a skeleton user account for FTP guests, these are files that would be useful to include in the skeleton guest user account so that they get installed automatically.

   Please note that this step is not necessary if you have used the --enable-ls option.

---

Top