Apart from the standard clauses defined in the /usr/newconfig/etc/ftpd/examples/ftpaccess file, the following additional clauses are available in the /etc/ftpd/ftpaccess file:
These clauses are explained in the following sections.
The email-on load Clause |
 |
Using this feature, you can specify email addresses for anonymous upload notifications. You can also specify a sender’s email address. By default, the sender’s address is specified as wu-ftpd. You can specify this for virtual hosts also. If the recipient attempts to reply to a notification, or if downstream mail problems generate bounces, ensure that the mailfrom address is a valid address, to avoid delivery problems.
The syntax for the email-on load feature is as follows:
virtual <address> incmail <emailaddress> |
defaultserver incmail <email address> |
virtual <address> mailfrom <emailaddress> |
defaultserver incmail <emailaddress> |
deny-email <case-insensitive-email-address> |
If you specify virtual host addresses, addresses only on a particular host receive notification messages of anonymous uploads. Otherwise, notifications are sent to the global addresses.
The defaultserver addresses apply only to real hosts and not to virtual hosts. Hence, the real host receives notifications of uploads on its default anonymous area. However, with this option set, the virtual hosts are not notified. For more information on the email-on-load feature, type man 4 ftpaccess at the HP-UX prompt.
Following are examples of the email-on-load feature:
Specifies the name of a mail server that accepts upload notifications for the FTP daemon. You can use this option to notify any user of anonymous uploads.
Specifies the email addresses to be notified of anonymous uploads.
Specifies the sender’s email address for anonymous upload notifications.
Timeouts |
|
You can configure timeout values used within the FTP daemon by using the timeout options. Table 2-2 describes the FTP daemon timeout values.
Table 2-2 FTP Daemon timeout Options
| Option | Description |
|---|
| accept | The time period for which the daemon waits for an incoming (PASV-passive) data connection. The default value is 120 seconds. |
| connect | The time period the daemon waits before attempting to establish an outgoing (PORT-port) data connection. The default value is 120 seconds. This affects the actual connection attempt. The daemon makes several attempts at regular intervals, sleeping between each attempt, before disconnecting. During the 120-minute timeframe, the daemon continues its attempt to establish a connection. If the daemon fails to establish a connection during this time period, it disconnects. |
| data | The time period the daemon waits for some activity on the data connection. The default value is 1200 seconds. |
| idle | The time period the daemon waits for the next command. The default value is 900 seconds. |
| RFC931 | The maximum time period for which the daemon allows for the entire RFC 931 (AUTH/ident) conversation. The default value is 10 seconds. |
| maxidle | The SITE IDLE command allows the remote client to establish a higher value for the idle timeout. With the maxidle option in the /etc/ftpd/ftpaccess file, you can override the value set with the SITE IDLE command. The default value is 1200 seconds. |
The timeout syntax is as follows:
timeout accept <seconds>
timeout connect <seconds>
timeout data <seconds>
timeout idle <seconds>
timeout maxidle <seconds>
timeout RFC931 <seconds> |
Following are some examples for the timeout clause:
Displays the message Current IDLE time limit is 200 seconds; max 7200
Displays the message Current IDLE time limit is 200 seconds; max 6200
Disables RFC 931-based authentication, because 0 is specified.
Enhanced DNS Extensions |
|
This feature is used to refuse (or override) an FTP session when a reverse DNS lookup fails.
The syntax for the enhanced DNS extension feature is as follows:
dns refuse_mismatch <filename> [ override ]
dns refuse_no_reverse <filename> [ override ]
dns resolveroptions <options> |
Reported Address Control |
|
This feature allows you to impose control on the address reported in response to a PASVcommand and on the TCP port numbers that can be used for a passive data connection. When a control connection matching the cidr (classless inter-domain routing) requests a passive data connection (PASV), the externalip address is reported.
The syntax for controlling the reported address is as follows:
passive address <externalip> <cidr> |
passive ports <cidr> <min> <max> |
Example 2-1 The passive Clause
The following are some examples for the passive clause:
passive address 10.0.1.15 10.0.0.0/8 |
In this example, clients connecting from the class A network - 10 are informed that the passive connection is listening on the IP address 10.0.1.15.
passive ports 10.0.0.0/8 90 100 |
In this example, if a control connection from the class A network - 10 exits, the port range within 90 and 100 is randomly selected for the daemon to listen to.
|
| |
|
 | NOTE: You cannot control the reported address in an IPv6 environment. |
|
| |
|
The keepalive Clause |
|
The keepalive clause allows you to control network disconnect by setting the TCP SO_ALIVE option for data sockets. You can specify yes to set the TCP option, or no to use the system default settings, which is usually off. HP recommends that you set the keepalive clause to yes to retain the network traffic connected.
The syntax for keepalive clause is as follows:
Clauses to Control Access to Areas on the FTP Site |
|
You can specify clauses to control whether a real or guest user is allowed access to areas on the FTP site other than their home directories.
The syntax for the clauses that control access to areas on the FTP site is as follows:
restricted-uid <uid-range>[...]
restricted-gid <gid-range>[...]
unrestricted-uid <uid-range>[...]
unrestricted-gid <gid-range>[...] |
|
| |
|
| NOTE: For all these clauses, you must copy the libraries /usr/lib/libnss_files.1 and /usr/lib/libdld.2 to the /usr/lib directory of the current environment. |
|
| |
|
Example 2-2 The restricted-uid and restricted-gid Clause
The following are some examples for the restricted-uid and restricted-gid clauses:
restricted-uid abtusera abtuserb
restricted-gid users abt |
These clauses do not replace the use of guestgroup and guestuser. Instead, you can use these clauses to supplement the operation of guests. You can use the unrestricted-uid and unrestricted-gid clauses to allow users who are otherwise restricted to use their home directories.
File Retrieval |
|
This feature allows you to retrieve files that are otherwise denied by the noretrieve clause. The allow-retrieve clause overrides the noretrieve clause.
The syntax for retrieving the files is as follows:
allow-retrieve [ absolute│relative ]
[ class= classname ] ... [-] filename |
Virtual Server |
|
Using the virtual server clauses, you can restrict user access to both the virtual and non-virtual domains. Also, you can use the options specified in the virtual clause to display the virtual host name.
The syntax for the virtual clause is as follows:
virtual <address> allow <username> [ username ...]
virtual <address> deny <username> [ username ...]
virtual <address> private
virtual <address> hostname│email string
defaultserver deny <username> [ username ...]
defaultserver allow <username> [ username ...]
defaultserver private |
Table 2-3 specifies different virtual clause examples.
Table 2-3 virtual Clause Options
| virtual Clause Option | Description |
|---|
virtual xx.xx.xx.xx allow root |
| Allows the root user to start the FTP session on the machine xx.xx.xx.xx. By default, real and guest users are not allowed to log in to the virtual server unless they are guests and have changed their directory to the virtual root directory. This is applicable only for virtual FTP servers. |
virtual xx.xx.xx.xx
allow *
virtual xx.xx.xx.xx deny
root |
| Denies root users and allows other users to start the FTP session. |
virtual xx.xx.xx.xx private |
| Denies service to anonymous FTP users. |
virtual xx.xx.xx.xx hostname telnet2.abc |
| Prints the string (telnet2.abc) instead of the actual host name in the greeting message and STAT command. |
| Denies ftp on the default FTP server for the root user. The message FTP LOGIN REFUSEDis logged in the /var/adm/syslog file. |
| Denies anonymous ftp connection to the default server. The message FTP LOGIN REFUSED is logged in the /var/adm/syslog file. |
Default Host Name |
|
This feature defines the default host name of the FTP server that is displayed in the greeting message. If you do not specify this clause, the default host name of the local machine is used.
The syntax for the specifying the default host name is as follows:
hostname <some.host.name> |
Example 2-3 The hostname Clause
An example for the hostname clause is as follows:
Displays the default host name (telnet2.123.com) instead of the actual host name in the greeting message.
Control Information |
|
This feature allows you to control the information specified in the greeting message before a remote user logs in. For the greeting message, you can specify the host name and daemon version, only the host name, or only the message FTP server ready. The default greeting clause is greeting full.
The syntax for the greeting clause is as follows:
greeting full│brief│terse |
Using the clause greeting text <message>, you can print a message different from the standard greeting message.
Example 2-4 The greeting Clause
An example for the greeting clause is as follows:
greeting text Hi!!! Welcome to FTP Server |
Displays the message Hi!!! Welcome to FTP server as the greeting message.
Session Time Limit |
|
This feature allows you to limit the total time for a session. By default, a limit is not set. Real users are never limited.
The syntax for limiting the total time of a session is as follows:
limit-time {*│anonymous│guest} <minutes> |
Treatment of UIDs and GIDs as Guests |
|
This feature allows you to force the UIDs and GIDs in a range to be treated as guests.
The syntax for treating UIDs and GIDs as guests is as follows:
guestuser <username> [ username ... ]
realgroup <groupname> [ groupname ... ]
realuser <username> [ username ... ] |
FTP Server Access to UID and GID Values |
|
This feature allows you to specify UID and GID values for which the FTP server access is denied or allowed. By default, allow access is set.
The syntax for denying or allowing FTP server access to UID and GID values is as follows:
deny-uid <uid-range>[...]
deny-gid <gid-range>[...]
allow-uid <uid-range>[...]
allow-gid <gid-range>[...] |
Example 2-5 The deny-gid, allow-gid and allow-uid Clauses
The following are some examples for the deny-gid, allow-gid, and allow-uid clauses:
deny-gid %-99 %65535 deny-uid %-99 %65535
allow-gid ftp
allow-uid ftp |
This denies FTP access to all privileged or special users and groups on a Linux system except the anonymous FTP user or group.
Upload and Download Ratios |
|
You can set the upload and download ratio to limit the user’s ability to upload and download files. By default, a ratio is not set.
The syntax for setting the upload and download ratio is as follows:
ul-dl-rate <rate> [ class ...]
dl-free <filename> [ class ...]
dl-free-dir <dirname> [ class ...] |
Example 2-6 The ul-dl-rate Clause
An example for the ul-dl-rate clause is as follows:
For every 1 byte of data that is uploaded, the ftp server allows 2 bytes of data to be downloaded.
The defumask Clause |
|
The defumask clause allows you to set umask for a file created by the ftp daemon if the remote user is a member of the named class. You can enter multiple defumask entries in the /etc/ftpd/ftpaccess file. If you do not specify a class for a defumask entry, then use umask as the default for classes that do not have a defumask entry.
The syntax for the defumask clause is as follows:
Example 2-7 The defumask Clause
The following are some examples for the defumask clause:
This creates files with the permission -rw-r--r-- for a user of ClassA. For other users, files are created with the permission -rw-------.
Limitations on the Number of Lines of Output |
|
This feature allows you to limit the number of lines of output that can be sent to the remote client. By default, the limit is set to 20.
The syntax for controlling the maximum number of lines of output is as follows:
site-exec-max-lines <number> [ class ...] |
Example 2-8 The site-exec-max-lines Clause
The following are some examples for the site-exec-max-lines clause:
site-exec-max-lines 200 remote
site-exec-max-lines 0 local
site-exec-max-lines 25 |
Example 2-8 contains three example statements for the site-exec-max-lines clause. The first example limits the output from SITE EXEC (therefore SITE INDEX) to 200 lines for remote users. The second example specifies no limit for local users. The third example sets a limit of 25 lines for all other users.
Root Directory Specification |
|
This feature specifies the root directory when a user logs in as an anonymous or guest user.
The syntax for specifying the root directory is as follows:
anonymous-root <root-dir> [ class ] |
guest-root <root-dir> [ uid-range ] |
Example 2-9 The anonymous-root Clause
The following are examples for the anonymous-root clause:
anonymous-root /home/localftp localnet |
Example 2-9 contains two examples for the anonymous-root clause. The first example changes the root directory of all the anonymous users to the directory /home/ftp, the anonymous user’s current working directory being the home directory. If an FTP user exists in the /home/ftp/etc/passwd file, the user’s current working directory is the home directory. In the second example, the root directory of all the anonymous users in the class localnet is changed to the directory/home/localftp, and the FTP user’s home directory in /home/localftp/etc/passwd specifies the initial current working directory.
Example 2-10 The guest-root Clause
An example for the guest-root clause is as follows:
guest-root /home/users guest-root /home/staff %100-999 sally |
The example changes the root directory of all the guest users to the /home/users directory. The directory of users in the range 100 through 999 and user sally is changed to the /home/staff directory, and the current working directory is obtained from their entries in the /home/staff/etc/passwd file.
Printable version
