Mac OS X Unleashed

Mac OS X Unleashed

By John Ray and William C. Ray

Using wu-ftpd as a Replacement for the Default ftpd

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

Although popular and highly configurable, wu-ftpd is not exempt from security problems. It is 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.1, as of this writing.

How to Replace ftpd with 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:

make install

When you download the wu-ftpd source files, also download any patches available for the source. Currently there are three patch files. Copy the patch files to the root directory of the source, and then run patch on the files as follows:

[localhost:~/wu-ftpd-2.6.1] software% patch -p0 < missing_format_strings.patch
[localhost:~/wu-ftpd-2.6.1] software% patch -p0 < nlst-shows-dirs.patch
[localhost:~/wu-ftpd-2.6.1] software% patch -p0 < pasv-port-allowcorection.patch

Please note that for display purposes, one of the actual patch filenames has been altered. The patches for the CHANGES file won't all work quite right, but don't worry about it because the CHANGES file is not as important as the other files that are patched.

The default config.guess and config.sub files that come with the wu-ftpd source do not work with OS X. Use the files that come with OS X:

[localhost:~ /wu-ftpd-2.6.1] software% cp /usr/libexec/config.guess ./
[localhost:~ -/wu-ftpd-2.6.1] software% cp /usr/libexec/config.sub ./

If you have not 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. 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 paramaters of a generic user, such as the u n known user. You might consider duplicating the unknown user and editing values. Suggested values for the bin user are shown in Table 25.3.

Table 25.3. 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 0
expire 0

Next, you are ready to run ./configure. Being the highly configurable package that it is, you can pass many parameters to configure, as detailed in Table 25.4.

Table 25.4. Available Options to configure for wu-ftpd

--with-etc-dir=PATH Path for configuration files; usually /etc.
--with-pid-dir=PATH Path for run/pid files; usually /var.
--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 ftpa c cess 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 supports 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. See doc/HOWTO/VIRTUAL.FTP.SUPPORT for details on 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 not to 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 e-mail 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. Although not documented, the -prefix parameter appears to work. 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/inetd.conf file to reflect the location of the new ftpd as well as any options that should be used. Options available in wu-ftpd are detailed in Table 25.5.

Table 25.5. Options Available in wu-ftpd

ftpd Internet File Transfer Protocol server
ftpd [-d] [-v] [-l] [-t <timeout>] [-T 
               <maxtimeout>] [-a] [-A] [-L] [-
i] [-I] [-o] [-p <ctrlport>] [-P <dataport>] [-q] [-Q] [-r <rootdir>]
[-s] [-S] [-u <mask>] [-V] [-w] [-X]
ftpd is the Internet File Transfer Protocol process. It uses the TCP protocol and runs on the port specified as ftp in the services directory of the NetInfo database.
-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 <maxtimeout> seconds. Default is two 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. Overriden 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.
-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.



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.



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, and then terminates.
-w Records every login and logout. This is the 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.
This ftpd supports the same FTP requests as the OS X default ftpd. The following nonstandard commands are supported by the SITE request:
UMASK Changes the umask; for example, SITE UMASK 002
IDLE Sets the idle timer; for example, SITE IDLE 60
CHMOD Changes the mode of a file; for example, SITE CHMOD 755 filename
HELP Gives help information; for example, SITE HELP
NEWER Lists files newer than a particular date
MINFO Like SITE NEWER, but gives extra information
GROUP Requests special group access; for example, SITE GROUP foo
GPASS Gives special group access password; for example, SITE GPASS bar
EXEC Executes a program; for example, SITE EXEC program params

Have inetd reread its configuration file:

[localhost:/Users/joray] root# ps -aux | grep inetd
     root       228   0.0  0.0     1260    108  ??  Ss     0:00.03 inetd
     root      6529   0.0  0.0     5708      0 std  T      0:00.00 grep inetd
[localhost:/Users/joray] root# kill -HUP 228

Editing the ftpaccess File

Although wu-ftpd provides a lot of configurability with its compile-time and run-time 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 25.6. Be sure to read the ftpaccess man page thoroughly for information on these and other available controls.

Table 25.6. 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> ...] Defines what groups are considered guests.
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 only 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. <d i rections> is a comma-separated list of the keyword 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, non-virutal 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.
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> Sets permissions for chmod, delete, overwrite, rename, umask as yes or no for users in <typelist> , where <typelist> is a comma-separated list of any of the skeywords real, anonymous, or guest.
umask <yes | no> <typelist>  
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 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 <type list> is a comma-separated list of any of the keywords real, anon y mous, or guest.
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 down load 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. Throughout the ftpaccess file where uid or gid can be specified, 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 > [...] restricted-gid < gid- range > [...] Controls whether real or guest users are allowed access to areas on the FTP server outside their home diretories. Not intended to replace the use of guestgroup and guestuser. The unrestricted clauses may be used to allow unrestricted-gid <gid- users unrestricted-gid <gid- 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 net mask of, use a CIDR of 8, and represents the network. Likewise, for a private class-C home network, you could use to represent your network.
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 ove r ride is specified, allows the connection after complaining.

Understanding Basic ftpaccess Controls

As you saw in Table 25.6, 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.


Look at this statement:

class   staff   real    *

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

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

class   local   guest   *

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.


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       SaSu|Any1800-0600       /usr/local/etc/msgs/msg.toomany

When the limit has been reached, any additional user will see 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.


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 uids.

Understanding the xferlog

By default, wu-ftpd logs transfers 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>

At a casual glance, that format might 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:

Fri May 11 13:32:19 2001 1 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 one second. The remote host was 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, we see that this was an incoming transfer; that is, an upload. From the a, we 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 0 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:

Fri May 11 16:32:24 2001 5 5470431
/Users/guests/betty/dotpaper.pdf b _ i g betty ftp 0 * c

It looks much like the anonymous entry. In this entry, we see that the transfer time was five 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:

Fri May 11 15:34:14 2001 1 277838
/Users/marvin/ b _ o r marvin ftp 0 * c

Again, this entry is much like the other two entries we have seen. In this example, we 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.

You will probably find that wu-ftpd logs to /var/log/ftpd.log as well. However, the log entries are more detailed than what you saw for the default FTP server. Take a look at it, too. It contains a lot of the same information as the xferlog, but it also includes information on passive mode, ports that were used, and so on.

Guest User Accounts

As you have seen, wu-ftpd understands three types of users: real, anonymous, and guest. Real users are users who have full login access to your machine. As you have also seen, 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 are not granted full access to your machine. Guest user accounts might be suitable for users who have Web sites on your machine and only need FTP access 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 does not have shell access to his account. Guest user accounts are also set up similarly to the anonymous FTP account. The users are restricted to only their home directories, 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 the 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 have decided where the guest account should reside, make a guest account. You could create your user in the User control panel. Your guest user, however, might not really have a need for all the directories that are made in a user account created by the User control panel. 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.
  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, we could create a guest user called betty, with a home directory located in /Users/guests/betty. To indicate that the root directory that we want betty to see when she accesses the FTP server to be /Users/guests/betty, we would edit the home directory to be /Users/guests/betty/./. If we wanted betty to be able to see a listing of other guest users' directories before changing to her directory, we could list her home directory as /Users/guests/./betty. By listing her home directory this way, her guest root directory does not need to be specifically listed in the ftpaccess file. Figure 25.3 shows how the guest user's home directory appears in the NetInfo Manager when indicated by this method.

    Figure 25.3 Here are the parameters we used for our guest user betty. Her home directory is listed in the traditional notation for a guest user, which includes a . to indicate the root directory the user will see when she FTPs.

    The other way to list a guest user's home directory is to list the home directory as usual in the NetInfo Manager. Then in the ftpaccess file, list the guest user's root directory with the guest-root control. With this method, the user's directory in the NetInfo database looks like the notation for any real user's home directory, as we see for guest user ralph in Figure 25.4.

    Figure 25.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 using the guest-root control in the ftpaccess file.

    The entry for the guest user's root directory in ftpaccess looks like this:
    guest-root /Users/guests/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
    are included in the guest user's home directory in ~/bin, ~/usr/lib and ~/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 guest user account, these are files that would be useful to include in the skeleton guest user account.

+ Share This