---
name: "sfs_users"
section: "5"
platform: "linux"
package: "sfs-server"
version: "1:0.8-0+pre20060720.1-1"
release: "Debian 4.0 (Etch)"
platforms: ["linux"]
url: "https://new.carta.tech/sfs_users"
---

# sfs\_users(5)

user-authentication database

## 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 roughly analogous to the Unix */etc/passwd* and */etc/group* files.  Each line of *sfs\_users* can specify a user or a group.  Users are specified 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 multiple 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 version 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 common to use the **unix=** property to map every SFS user to a local Unix user of the same name.  The **unix=** property has several consequences. 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 administrative privileges in SFS.  The option has no effect unless the **Userfile** directive in *sfsauthd\_config* specifies the **-admin** option.  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 distribution yet.

- srp

  *srp* is the server-side information for the SRP protocol.  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 particular 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 private, per-user data that **sfsauthd** will return to users who successfully 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 description 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**, while the remaining fields have the following meanings:

- 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 membership 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 distribution yet.

- audit

  Information about the last time this record was modified through the **sfskey** interface.

*sfs\_users* files can be stored in one of three formats:  plain ASCII, database directories, and database files.  (The latter two require SFS to have been compiled with Sleepycat BerkeleyDB support.) The format is determined by the extension of the file name.  File names ending *.db/* are considered database directories; file names ending *.db* are considered database files; everything 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 auxiliary files.)

You should always edit *sfs\_users* files using the [**vidb**(8)](/vidb/8.md) 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** translates from the binary database format into the ASCII format described above; when committing updates, it also atomically modifies 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)](/dirsearch/1.md), [*newaid*(1)](/newaid/1.md), [*rex*(1)](/rex/1.md), [*sfsagent*(1)](/sfsagent/1.md), [*sfskey*(1)](/sfskey/1.md), [*ssu*(1)](/ssu/1.md), *sfs\_config*(5), [*sfs\_hosts*(5)](/sfs_hosts/5.md), [*sfs\_srp\_params*(5)](/sfs_srp_params/5.md), [*sfsauthd\_config*(5)](/sfsauthd_config/5.md), [*sfscd\_config*(5)](/sfscd_config/5.md), *sfsrosd\_config*(5), [*sfsrwsd\_config*(5)](/sfsrwsd_config/5.md), [*sfssd\_config*(5)](/sfssd_config/5.md), [*sfs\_environ*(7)](/sfs_environ/7.md), [*funmount*(8)](/funmount/8.md), *nfsmounter*(8), [*sfsauthd*(8)](/sfsauthd/8.md), [*sfscd*(8)](/sfscd/8.md), *sfsrosd*(8), *sfsrwcd*(8), [*sfsrwsd*(8)](/sfsrwsd/8.md), [*sfssd*(8)](/sfssd/8.md), [*vidb*(8)](/vidb/8.md)

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