isdn4k-utils/eurofile/doc/eftaccess.5

335 lines
12 KiB
Groff

.\" $Id: eftaccess.5,v 1.1 1999/06/30 16:51:04 he Exp $
.\" SCCSID: @(#)$Original-Id: ftpaccess.5,v 1.7 1997/01/10 06:27:02 sob Exp $
.\"
.\"
.TH eftaccess 5
.SH Name
eftaccess \- eftd configuration file
.SH Description
The eftaccess file is used to configure the operation of
.BR eftd(1) .
.SH Access Capabilities
.TP 0.5i
.B autogroup <groupname> <class> [<class> ...]
If an ANONYMOUS user is a member of any of <class>, the ftp
server will perform a setegid() to <groupname>. This allows
access to group-and-owner-read-only files and directories to
a particular class of anonymous users. <groupname> is a valid
group from /etc/group (or wherever mechanism your
.IR getgrent(2)
library routine uses).
.TP 0.5i
.B class <class> <typelist> <addrglob> [<addrglob> ...]
Define <class> of users, with source addresses of the form
<addrglob>. Multiple members of <class> may be defined. There
may be multiple "class" commands listing additional members of
the class. If multiple "class" commands can apply to the
current session, the first one listed in the access file is
used. Failing to define a valid class for a host will cause
access to be denied. <typelist> is a comma-separated list of
any of the keywords "anonymous", "guest" and "real". If the
"real" keyword is included, the class can match users using FTP
to access real accounts, and if the "anonymous" keyword is
included the class can match users using anonymous FTP. The
"guest" keyword matches guest access accounts (see "guestgroup"
for more information)
<addrglob> may be a globbed isdn number.
.TP 0.5i
.B deny <addrglob> <message_file>
Always deny access to host(s) matching <addrglob>. <message_file>
is displayed.
.TP 0.5i
.B guestgroup <groupname> [<groupname> ...]
If a REAL user is a member of any of <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 /etc/group (or whatever mechanism your
.IR getgrent(3)
library routine uses).
The user's home directory must be properly set up, exactly as
anonymous FTP would be. The home directory field of the
passwd entry is divided into two directories. The first
field is the root directory which will be the argument
to the
.IR chroot(2)
call. The second half is the user's
home directory relative to the root directory. The
two halves are separated by a "/./".
Example:
in /etc/passwd, the real entry:
guest1:<passwd>:100:92:Guest Account:/ftp/./incoming:/etc/ftponly
When guest1 successfully logs in, the ftp server will
chroot("/ftp") and then chdir("/incoming"). The
guest user will only be able to access the directory structure
under /ftp (which will look and act as / to guest1), just as an
anonymous FTP user would.
.TP 0.5i
.B limit <class> <n> <times> <message_file>
(currently not applicable to eftd)
.P
Limit <class> to <n> users at times <times>, displaying
<message_file> if user is denied access. Limit check is
performed at login time only. If multiple "limit" commands can
apply to the current session, the first applicable one is
used. Failing to define a valid limit, or a limit of -1, is
equivalent to unlimited. <times> is in same format as the times
in the UUCP L.sys file.
.TP 0.5i
.B noretrieve <filename> <filename> ....
(currently not applicable to eftd)
.P
Always deny retrieve-ability of these files. If the files are an
absolute path specification (i.e. begins with '/' character) then
only those files are marked un-gettable, otherwise all files with
matching the filename are refused transfer. Example:
noretrieve /etc/passwd core
specifies no one will be able to get the file /etc/passwd whereas
they will be allowed to transfer a file `passwd' if it is not in
/etc. On the other hand no one will be able to get files named
`core' wherever it is.
No globbing is done.
.TP 0.5i
.B loginfails <number>
(currently not applicable to eftd)
.P
After <number> login failures, log a "repeated login failures"
message and terminate the FTP connection. Default value is 5.
.TP 0.5i
.SH Informational Capabilities
.TP 0.5i
.B banner <path>
Works similarly to the message command, except that the banner
is displayed before the user enters the username/password. The
<path> is relative to the real system root, not the base of the
anonymous FTP directory.
.TP 0.5i
.B email <name>
Defines the email address of the ftp archive maintainer. This string
will be printed every time the %E magic cookie is used.
.TP 0.5i
.B message <path> {<when> {<class> ...}}
(currently not applicable to eftd)
.P
Define a file with <path> such that ftpd will display the
contents of the file to the user login time or upon using the
change working directory command. The <when> parameter may be
"LOGIN" or "CWD=<dir>". If <when> is "CWD=<dir>", <dir>
specifies the new default directory which will trigger the
notification.
The optional <class> specification allows the message to be
displayed only to members of a particular class. More than one
class may be specified.
There can be "magic cookies" in the readme file which cause the
ftp server to replace the cookie with a specified text string:
%T local time (form Thu Nov 15 17:12:42 1990)
%F free space in partition of CWD (kbytes)
[not supported on all systems]
%C current working directory
%E the maintainer's email address as defined in ftpaccess
%R remote host name
%L local host name
%u username as determined via RFC931 authentication
%U username given at login time
%M maximum allowed number of users in this class
%N current number of users in this class
The message will only be displayed once to avoid annoying the
user. Remember that when MESSAGEs are triggered by an
anonymous FTP user, the <path> must be relative to the base of
the anonymous FTP directory tree.
.TP 0.5i
.B readme <path> {<when> {<class>}}
Define a file with <path> such that ftpd will notify user at
login time or upon using the change working directory command
that the file exists and was modified on such-and-such date.
The <when> parameter may be "LOGIN" or "CWD=<dir>". If <when>
is "CWD=<dir>", <dir> specifies the new default directory which
will trigger the notification. The message will only be
displayed once, to avoid bothering users. Remember that when
README messages are triggered by an anonymous FTP user, the
<path> must be relative to the base of the anonymous FTP
directory tree.
The optional <class> specification allows the message to be
displayed only to members of a particular class. More than one
class may be specified.
.SH Logging Capabilities
.TP 0.5i
.B log commands <typelist>
Enables logging of individual commands by users. <typelist> is
a comma-separated list of any of the keywords "anonymous",
"guest" and "real". If the "real" keyword is included, logging
will be done for users using FTP to access real accounts, and
if the "anonymous" keyword is included logging will done for
users using anonymous FTP. The "guest" keyword matches guest
access accounts (see "guestgroup" for more information).
.TP 0.5i
.B log transfers <typelist> <directions>
Enables logging of file transfers for either real or anonymous
FTP users. Logging of transfers TO the server (incoming) can
be enabled separately from transfers FROM the server
(outbound). <typelist> is a comma-separated list of any of the
keywords "anonymous", "guest" and "real". If the "real"
keyword is included, logging will be done for users using FTP
to access real accounts, and if the "anonymous" keyword is
included logging will done for users using anonymous FTP. The
"guest" keyword matches guest access accounts (see "guestgroup"
for more information). <directions> is a comma-separated list
of any of the two keywords "inbound" and "outbound", and will
respectively cause transfers to be logged for files sent to the
server and sent from the server.
.SH Miscellaneous Capabilities
.TP 0.5i
.B alias <string> <dir>
Defines an alias, <string>, for a directory. Can be
used to add the concept of logical directories.
For example:
alias rfc: /pub/doc/rfc
would allow the user to access /pub/doc/rfc from any
directory by the command "cd rfc:". Aliases only
apply to the cd command.
.TP 0.5i
.B cdpath <dir>
Defines an entry in the cdpath. This defines a search path that is used
when changing directories.
For example:
cdpath /pub/packages
cdpath /.aliases
would allow the user to cd into any directory directly under
/pub/packages or /.aliases directories. The search path is defined by
the order the lines appear in the ftpaccess file.
If the user were to give the command:
cd foo
The directory will be searched for in the following order:
./foo
an alias called "foo"
/pub/packages/foo
/.aliases/foo
The cd path is only available with the cd command. If you have a large
number of aliases you might want to set up an aliases directory with
links to all of the areas you wish to make available to users.
.TP 0.5i
.SH Permission Capabilities
(currently not applicable to eftd)
.P
.TP 0.5i
.B chmod <yes|no> <typelist>
.TP 0.5i
.B delete <yes|no> <typelist>
.TP 0.5i
.B overwrite <yes|no> <typelist>
.TP 0.5i
.B rename <yes|no> <typelist>
.TP 0.5i
.B umask <yes|no> <typelist>
Allows or disallows the ability to perform
the specified function. By default, all users
are allowed.
<typelist> is a comma-separated list of any of the
keywords "anonymous", "guest" and "real".
.TP 0.5i
.B passwd-check <none|trivial|rfc822> (<enforce|warn>)
Define the level and enforcement of password checking
done by the server for anonymous ftp.
none no password checking performed.
trivial password must contain an '@'.
rfc822 password must be an rfc822 compliant address.
warn warn the user, but allow them to log in.
enforce warn the user, and then log them out.
.TP 0.5i
.B path-filter <typelist> <mesg> <allowed_charset> {<disallowed regexp> ...}
(currently not applicable to eftd)
.P
For users in <typelist>, path-filter defines regular expressions
that control what a filename can or can not be. There may be
multiple disallowed regexps. If a filename is invalid due to
failure to match the regexp criteria, <mesg> will be displayed to
the user. For example:
path-filter anonymous /etc/pathmsg ^[-A-Za-z0-9\._]*$ ^\. ^-
specifies that all upload filenames for anonymous users must be
made of only the characters A-Z, a-z, 0-9, and "._-" and may not
begin with a "." or a "-". If the filename is invalid, /etc/pathmsg
will be displayed to the user.
.TP 0.5i
.B upload <root-dir> <dirglob> <yes|no> <owner> <group> <mode> ["dirs"|"nodirs"]
Define a directory with <dirglob> that permits or
denies uploads.
If it does permit uploads, all files will be owned
by <owner> and <group> and will have the permissions
set according to <mode>.
Directories are matched on a best-match basis.
For example:
upload /var/ftp * no
upload /var/ftp /incoming yes ftp daemon 0666
upload /var/ftp /incoming/gifs yes jlc guest 0600 nodirs
This would only allow uploads into /incoming and
/incoming/gifs. Files that were uploaded to
/incoming would be owned by ftp/daemon and would
have permissions of 0666. File uploaded to
/incoming/gifs would be owned by jlc/guest and
have permissions of 0600. Note that the <root-dir> here must
match the home directory specified in the password database for the
"ftp" user.
The optional "dirs" and "nodirs" keywords can be
specified to allow or disallow the creation of
new subdirectories using the mkdir command.
The upload keyword only applies to users who
have a home directory (the argument to the chroot() )
of <root-dir>.
.SH Files
FTPLIB/ftpaccess
.SH See Also
.BR ftpd(8),
.BR umask(2) ,
.BR ftplog(5) ,
.BR ftpconversions(5) ,
.BR ftpshut(8)
.SH BUGS
The eftaccess features are mainly untested. Most of this man page is
not finished. In particular, don't expect any feature to work that is
used for anything else but authenticating a user logging in.