sfs_users(5)

NAME

sfs_users - user-authentication database

DESCRIPTION

The sfs_users file, maintained and used by the sfsauthd

program, maps public keys to local users and groups. It is rough

ly analogous to the Unix /etc/passwd and /etc/group files. Each

line of sfs_users can specify a user or a group. Users are spec

ified as follows (split into two lines here only for clarity of

presentation):

USER:user:uid:version:gid:owner:pubkey:privs

:srp:privkey:srvprivkey:audit

Note that the first USER is just the literal string USER.

The rest of the fields have the following meanings:

user

user is the unique name of a public key in the

database. Ordinarily it is the same as a username in the local

password file. However, it is also possible to add SFS users who

do not have local Unix accounts. It is also possible map multi

ple public keys to the same local Unix account, as when several

people have an account with root privileges. In such cases, each

key should be given a unique name (e.g., dm/root, kaminsky/root,

etc.).

uid uid is the user's user ID on the given server.

version

version is the version number of this record in the

users database. Upon registration, this value is set to 1. Upon

every subsequent update, this value is incremented by 1.

gid gid is the users's group ID on the given server.

owner

This field is currently ignored, but in a future ver

sion may be used to allow users to create ``guest'' accounts.

pubkey

pubkey is an ASCII, human-readable representation of

the user's public key. Can be either a Rabin or 2-Schnorr public

key.

privs

The privs field contains a comma-separated list of

properties of the account. Possible properties are as follows:

unix=account

This property states that an SFS user corresponds

to the local Unix account account. In many settings, it is com

mon to use the unix= property to map every SFS user to a local

Unix user of the same name. The unix= property has several con

sequences. First, if there is no local Unix user named account,

this SFS user will not be allowed to log in. Second, when the

SFS user logs in, SFS will search /etc/group for additional

groups the user might belong to. Third, the rexd remote login

daemon will allow remote login access to this account, using the

shell and home directory specified in /etc/passwd. Finally, on

some operating systems, SFS enforces account expiration dates

specified by /etc/shadow or /etc/spwd.db.

admin

Indicates that this particular users has adminis

trative privileges in SFS. The option has no effect unless the

Userfile

tion. For sfs_users files with the -admin option, the admin privilege allows users to create and modify other user records
remotely, though currently client-side support for doing this is
limited.
refresh
timeout

These properties are mostly of use with sfsaclsd,

an experimental server that is not part of the mainline SFS dis

tribution yet.

srp srp is the server-side information for the SRP proto

col. Unlike the previous fields, this information must be kept

secret. If the information is disclosed, an attacker may be able

to impersonate the server by causing the sfskey add command to

fetch the wrong HostID. Note also that srp is specific to a par

ticular hostname. If you change the Location of a file server,

users will need to register new SRP.

privkey

privkey is actually opaque to sfsauthd. It is pri

vate, per-user data that sfsauthd will return to users who suc

cessfully complete the SRP protocol. Currently, sfskey users

this field to store an encrypted copy of a user's private key,

allowing the user to retrieve the private key over the network.

srvprivkey

If a user has chosen 2-Schnorr proactive signatures,

the server's half of the private key is kept in this field.

audit

audit contains the time, source IP address, and de

scription of the last update to this field. Useful in recovering

from a compromised key.

Each group in sfs_users is specified by a line with the

following format:

GROUP:group:gid:version:owners:members:properties:audit

Here again the first GROUP is just the literal string

GROUP

group

The name of the group.

gid The numeric group ID.

version

version is the version number of this record in the

database. The number increments when people edit groups through

the sfskey interface.

owners

List of users who are allowed to edit the group mem

bership list.

members

List of users who are in the group.

properties

Properties of the group, mostly of use with sfsaclsd,

an experimental server that is not part of the mainline SFS dis

tribution yet.

audit

Information about the last time this record was modi

fied through the sfskey interface.

sfs_users files can be stored in one of three formats:

plain ASCII, database directories, and database files. (The lat

ter two require SFS to have been compiled with Sleepycat Berke

leyDB support.) The format is determined by the extension of the

file name. File names ending .db/ are considered database direc

tories; file names ending .db are considered database files; ev

erything else is considered ASCII. Only read-only and exported

public databases can be database files; read-write databases must

be directories, ending .db/. (The reason is that read-write

database files require write-ahead logging, which relies on aux

iliary files.)

You should always edit sfs_users files using the vidb(8)

command, for two reasons. First, whenever editing files by hand,

you run the risk of overwriting concurrent updates by sfsauthd.

vidb acquires the necessary locks to prevent this from happening.

Second, when editing a database directory or file, vidb trans

lates from the binary database format into the ASCII format de

scribed above; when committing updates, it also atomically modi

fies various secondary indexes that SFS relies upon.

FILES

/etc/sfs/sfs_users
/usr/local/share/sfs/sfs_users

user-authentication database

(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),

sfsauthd_config(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

SFS_USERS(5)