Provided by: sfs-server_0.8-0+pre20060720.1-1.1_i386


        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=pub‐
        path] [-prefix=prefix] [-uid=uid | -uidmap=u1-u2+u3] [-gid=gid |
        -gidmap=g1-g2+g3] [-groups=g1-g2] [-groupquota=limit] [-refresh=sec‐
        onds] [-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 envi‐
            ronment 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 direc‐
            tory.  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 pass‐
                words, 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 sepa‐
                rate 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 num‐
                ber 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-adminis‐
                trative user can create.  Administrative users have the ‘admin’
                keyword in the ‘privs’ field of their user entry.  The authen‐
                tication server also looks for the pattern ‘groupquota=<limit>’
                in the user record; if found, that per-user quota takes prece‐
                dence 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 unlimited.
                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 unavail‐
                able--the entity can continue to use its cached copy of this
                record for seconds seconds since the last time it was success‐
                fully 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.  Authentica‐
            tion 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 reg‐
            istered 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 sig‐
            nify 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 direc‐
            tive 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 path‐
            name (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), sfs‐
        rosd(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 com‐
        mand info SFS should give you access to the complete manual.
        For updates, documentation, and software distribution, please see the
        SFS website at