Provided by: sfs-server_0.8-0+pre20050819.1-2_i386 bug


       sfsauthd_config - user-authentication daemon configuration


       Hostname name
           Set the Location part of the server’s self-certifying pathname.
           The default is the current host’s fully-qualified hostname.

       Keyfile path
           Tells sfsrwsd to look for its private key in file path.  The
           default is sfs_host_key.  SFS looks for file names that do not
           start with / in /etc/sfs, or whatever directory you specified if
           you used the -with-etcdir option to configure ().

       Userfile [-update] [-create] [-passwd] [-admin] [-hideusers]
       [-pub=pubpath] [-prefix=prefix] [-uid=uid │ -uidmap=u1-u2+u3] [-gid=gid
       │ -gidmap=g1-g2+g3] [-groups=g1-g2] [-groupquota=limit]
       [-refresh=seconds] [-timeout=seconds] path
           This specifies a file in which sfsauthd should look for user public
           keys when authenticating users.  You can specify multiple Userfile
           directives to use multiple files.  This can be useful in an
           environment where most user accounts are centrally maintained, but
           a particular server has a few locally-maintained guest (or root)

           If sfsauthd has been compiled with Sleepycat database
           ( support, and path ends in .db/, vidb
           will consider the user authentication file to be a database
           directory.  This offers considerably greater efficiency for large
           databases, as databases directories most operations O(log n) rather
           than O(n) for flat text files.  If path ends in .db, it is assumed
           to be a database file.  Database files are similar to database
           directories, but can only be used for read-only databases (as they
           do not support atomic transactions).  Database files should be used
           to export databases via the -pub=pubpath option, and to import
           read-only databases (by omitting the -update option).

           Userfile has the following options:

               Specifies a user database as updatable.  Users can register new
               public keys, update their public keys, and change their server
               key information on writable databases.  If this command is not
               given, the database is assumed to be read-only and possibly on
               a remote machine.  Thus, sfsauthd maintains local copies of
               read-only databases in /var/sfs/authdb.  This process ensures
               that temporarily unavailable file servers never disrupt
               sfsauthd’s operation.

               Create an empty sfs_users file if no such file exists.

               Treat the Unix passwd file (/etc/passwd on most machines) as
               part of this userfile.  Use password, shell and home directory
               information.  Allows users who do not exist in the database to
               log into sfsauthd with their UNIX password, so that they might
               register an SFS key (note this also requires the -update flag).
               See sfskey register, for details on this. Also important for
               proper functioning of rexd.

               Allow an SFS administrator to make changes to user records that
               have the admin flag set in their privs field.

               When replying to group queries, replace local user names (that
               appear in the ownership or membership lists) with a hash of the
               user’s public key.

               sfsauthd supports the secure remote password protocol, or SRP.
               SRP lets users connect securely to sfsauthd with their
               passwords, without needing to remember the server’s public key.
               To prove its identity through SRP, the server must store secret
               data derived from a user’s password.  The file path specified
               in Userfile contains these secrets for users opting to use SRP.
               The -pub option tells sfsauthd to maintain in pubpath a
               separate copy of the database without secret information.
               pubpath might reside on an anonymously readable SFS file
               system--other machines can then import the file as a read-only
               database using a Userfile line with the -update flag.

               Prepend the prefix prefix to usernames in the given userfile.

               These options are mutually exclusive.  The first maps every
               user’s credentials in the given file to the given UID, uid.
               The second maps users in the UID range (u1 to u2) to the offset
               u3.  For example, if you wanted to map users to 1000-2520 to
               61000-62520, you would supply -uidmap=1000-2520+60000.

               See above.  Functions the same as uid and uidmap, but applies
               to group IDs, rather than user IDs.  Again, these options are
               mutually exclusive.

               This option tells sfsauthd to allow regular (non-admin) users
               to add groups.  New group IDs will be in the range g1 to g2.
               Administrators can establish per-user quotas to limit the
               number of groups that a particular user can create.  User
               quotas are listed in the privs field of user records as
               "groupquota"=quota where quota is an unsigned integer.

               Set the default maximum number of groups that any non-
               administrative user can create.  Administrative users have the
               ‘admin’ keyword in the ‘privs’ field of their user entry.  The
               authentication server also looks for the pattern
               ‘groupquota=<limit>’ in the user record; if found, that per-
               user quota takes precedence and overrides this global
               (UserFile-wide) setting.  If no group quota is specified in
               either place, the number of groups that a user can create is

               This option allows the administrator to set a default refresh
               value for newly created users and/or groups in this database.
               The refresh value is stored with the user and/or group record
               and is retured with the record in response to database queries.
               The refresh value tells the entity who is fetching the record
               that it can continue to use its cached copy of this record for
               seconds seconds since the last time it was successfully
               updated.  That is, the record does not need refreshing for at
               least seconds seconds.  If unspecified, the current system
               default is 3600 seconds (1 hour).

               This option allows the administrator to set a default timeout
               value for newly created users and/or groups in this database.
               The timeout value is stored with the user and/or group record
               and is retured with the record in response to database queries.
               The timeout value tells the entity who is fetching the record
               that--in the event that the authentication server is
               unavailable--the entity can continue to use its cached copy of
               this record for seconds seconds since the last time it was
               successfully updated.  If unspecified, the current system
               default is 604800 seconds (1 week).

           If no Userfile directive is specified, sfsauthd uses the following
           default (again, unqualified names are assumed to be in /etc/sfs):

             Userfile -update -passwd sfs_users

       DBcache path
           The path to the database that holds the authentication server’s
           cache.  If unspecified, it defaults to one of the two entries shown
           below.  The first applies if Sleepycat (BerkeleyDB) support was
           compiled in; otherwise, the second entry applies.  If path begins
           with a "/" (slash), it is taken to be an absolute path.  If not, it
           is a path relative to /var/sfs/authdb.

             dbcache dbcache.db/
             dbcache dbcache

       DBcache_refresh_delay seconds
           Specify the frequency (in seconds) that sfsauthd will attempt to
           refresh its cache.  This value only serves as a minimum because the
           server will not attempt to download a remote user or group more
           frequently than its individual refresh value (set by the remote
           administrator or user).  The special value ‘off’ disables the
           authentication cache as well as symbolic and/or recursive groups.
           The default is ‘off’.

             dbcache_refresh_delay off
             dbcache_refresh_delay 3600

       Logfile path
           Use the logfile given by path to output the signature log generated
           by sfsauthd.  The default logfile is /var/sfs/sign_log.

       SRPfile path
           Where to find default parameters for the SRP protocol.  Generate
           such a file using the sfskey gensrp command. The default is
           sfs_srp_params.  If the default file does not exist, serving pre-
           generated SRP parameters is disabled.

       Denyfile path
           Specify a file containing a list of users that are to be explicitly
           denied the ability to register and update keys on the authserver.
           The default is sfs_deny.  If the default file does not exist, we
           assume an empty list.

       Realm name
           Define the realm to which this authserver will belong.
           Authentication information (including SRP) can be shared amongst
           authservers that are in the same realm.  Thus, a user that wants to
           login to a realm, can contact any authserver in that realm.

           If the realm directive does NOT appear in this file, the authserver
           will not join any realm.  This behavior is the default.  If the
           realm directive does appear, name cannot be empty.

           NOTE: Changing an authserver’s realm after users have already
           registered using SRP requires all users to update their
           authentication data because the realm is bound into the stored SRP
           information.  Specifically, each user will need to run

             sfskey update -r username@authserver

           A user logged on to the authserver can use the hostname - to
           signify the local host:

             sfskey update -r -

       Certpath dir [dir ...]
           Specify a certification path to return to the client as a result of
           an sfskey login command; this list of directories will become the
           arguments to a dirsearch certprog.  That is, for a certpath "dir1
           dir2" the client will add a certprog "dirsearch dir1 dir2" to the
           user’s agent.  The certification path will be tagged with a prefix
           equal to the authserver’s realm (see above).

           NOTE: The certpath directive only makes sense if the authserver is
           part of a realm.  The certpath will be ignored if the realm
           directive isn’t specified.

           There are three ways to specify a certpath directory:

             certpath //dir1 /dir2,HOSTID/dir2

           which can also be written

             certpath //dir1
             certpath /dir2

           A directory starting with two slashes ("//") is considered relative
           to the client machine’s root ("/").  A directory starting with one
           slash ("/") is relative to the authserver’s self-certifying
           pathname (the authserver performs the substitution before is sends
           the dir).  The third form is a fully specified directory on SFS.

           The default certpath is empty.


           user-authentication daemon configuration

       (Files in /etc/sfs supersede default versions in /usr/local/share/sfs.)


       dirsearch(1), newaid(1), rex(1), sfsagent(1), sfskey(1), ssu(1),
       sfs_config(5), sfs_hosts(5), sfs_srp_params(5), sfs_users(5),
       sfscd_config(5), sfsrosd_config(5), sfsrwsd_config(5), sfssd_config(5),
       sfs_environ(7), funmount(8), nfsmounter(8), sfsauthd(8), sfscd(8),
       sfsrosd(8), sfsrwcd(8), sfsrwsd(8), sfssd(8), vidb(8)

       The full documentation for SFS is maintained as a Texinfo manual.  If
       the info and SFS programs are properly installed at your site, the
       command info SFS should give you access to the complete manual.

       For updates, documentation, and software distribution, please see the
       SFS website at