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

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.  Ordinar‐
            ily it is the same as a username in the local password file.  How‐
            ever, 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 speci‐
                fied by /etc/shadow or /etc/spwd.db.
 
            admin
                Indicates that this particular users has administrative privi‐
                leges 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 experimen‐
                tal 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 for‐
        mat:
 
        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 inter‐
            face.
 
        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 experimen‐
            tal 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) command, for
        two reasons.  First, whenever editing files by hand, you run the risk
        of overwriting concurrent updates by sfsauthd.  vidb acquires the nec‐
        essary 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.)
        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), 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 http://www.fs.net/.
 

AUTHOR

        sfsdev@redlab.lcs.mit.edu