sfsauthd_config(5)

NAME

sfsauthd_config - user-authentication daemon configuration

DESCRIPTION

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) accounts.

If sfsauthd has been compiled with Sleepycat database

(http://www.sleepycat.com/) support, and path ends in .db/, vidb

will consider the user authentication file to be a database di

rectory. 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 databas

es (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 op

tion).

Userfile has the following options:

-update

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 com

mand 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

Create an empty sfs_users file if no such file ex

ists.

-passwd

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.

-admin

Allow an SFS administrator to make changes to user

records that have the admin flag set in their privs field.

-hideusers

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.

-pub=pubpath

sfsauthd supports the secure remote password pro

tocol, 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 speci

fied 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 sys

tem--other machines can then import the file as a read-only

database using a Userfile line with the -update flag.

-prefix=prefix

Prepend the prefix prefix to usernames in the giv

en userfile.

-uid=uid
-uidmap=u1-u2+u3

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.

-gid=gid
-gidmap=g1-g2+g3

See above. Functions the same as uid and uidmap,

but applies to group IDs, rather than user IDs. Again, these op

tions are mutually exclusive.

-groups=g1-g2

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.

-groupquota=limit

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 `groupquo

ta=<limit>' in the user record; if found, that per-user quota

takes precedence and overrides this global (UserFile-wide) set

ting. If no group quota is specified in either place, the number

of groups that a user can create is unlimited.

-refresh=seconds

This option allows the administrator to set a de

fault 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 up

dated. That is, the record does not need refreshing for at least

seconds seconds. If unspecified, the current system default is

3600 seconds (1 hour).

-timeout=seconds

This option allows the administrator to set a de

fault 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 un

available--the entity can continue to use its cached copy of this

record for seconds seconds since the last time it was successful

ly 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 -pub=sfs_users.pub

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 mini

mum 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 re

cursive 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 de

fault. 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 host

name - 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 @sfs.host.domain,HOSTID/dir2

which can also be written

certpath //dir1
certpath /dir2
certpath @sfs.host.domain,HOSTID/dir2

A directory starting with two slashes ("//") is con

sidered 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 substitu

tion before is sends the dir). The third form is a fully speci

fied directory on SFS.

The default certpath is empty.

FILES

/etc/sfs/sfsauthd_config /usr/local/share/sfs/sfsauthd_config

user-authentication daemon configuration

(Files in /etc/sfs supersede default versions in

/usr/local/share/sfs.)

SEE ALSO

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 http://www.fs.net/.

AUTHOR

sfsdev@redlab.lcs.mit.edu

SFS 0.8pre 2006-07-20 SF

SAUTHD_CONFIG(5)