9srv Manual Collection/plan9/factotum(4) | 9srv Manual Collection/plan9/factotum(4) |
---|
auth/factotum -g attribute=value ... attribute? ...
auth/fgui
Factotum presents a two level directory. The first level contains a single directory factotum, which in turn contains:
In any authentication, the caller typically acts as a client and the callee as a server. The server determines the authentication domain, sometimes after a negotiation with the client. Authentication always requires the client to prove its identity to the server. Under some protocols, the authentication is mutual. Proof is accomplished using secret information kept by factotum in conjunction with a cryptographic protocol.
Factotum can act in the role of client for any process possessing the same user id as it. For select protocols such as p9sk1 it can also act as a client for other processes provided its user id may speak for the other process' user id (see authsrv(6)). Factotum can act in the role of server for any process.
Factotum's structure is independent of any particular authentication protocol. Factotum supports the following protocols:
The options are:
Fgui is a graphic user interface for confirming key usage and entering new keys. It hides the window in which it starts and waits reading requests from confirm and needkey. For each requests, it unhides itself and waits for user input. See the sections on key confirmation and key prompting below.
P9sk1, p9sk2, and p9cr all require a key with proto=p9sk1, a dom attribute identifying the authentication domain, a user name valid in that domain, and either a !password or !hex attribute specifying the password or hexadecimal secret to be used. Here is an example:
Apop, cram, chap, and mschap, require a key with a proto attribute whose value matches the protocol, in addition to server, user, and !password attributes; e.g.
Pass requires a key with proto=pass in addition to user and !password attributes; e.g.
Rsa requires a key with proto=rsa in addition to all the hex attributes defining an RSA key: ek, n, !p, !q, !kp, !kq, !c2, and !dk. By convention, programs using the RSA protocol also require a service attribute set to ssh, sshserve, or tls.
Wep requires a key1, key2, or key3 set to the password to be used. Starting the protocol causes factotum to configure the wireless ethernet card #l/ether0 for WEP encryption with the given password.
All keys can have additional attributes that act either as comments or as selectors to distinguish them in the auth(2) library calls.
The factotum owner can use any key stored by factotum. Any key may have one or more owner attributes listing the users who can use the key as though they were the owner. For example, the TLS and SSH host keys on a server often have an attribute owner=* to allow any user (and in particular, none) to run the TLS or SSH server-side protocol.
Any key may have a role attribute for restricting how it can be used. If this attribute is missing, the key can be used in any role. The possible values are:
If a key has a disabled attribute (with any value), the key is not used during any protocols. Factotum automatically marks keys with disabled=by.factotum when they fail during certain authentication protocols (in particular, the Plan 9 ones).
Whenever factotum runs as a server, it must have a p9sk1 key in order to communicate with the authentication server for validating passwords and challenge/responses of other users.
Key templates are also used by factotum to request a key either via an RPC error or via the needkey interface. The possible attribute/value formats are:
By default when factotum starts it looks for a
secstore(1)
account on $auth for the user and, if one exists,
prompts for a secstore password in order to fetch
the file
factotum,
which should contain control file commands.
An example would be
confirm tag=tagno <key template>
The reply, written back to confirm, consists of string:
tag=tagno answer=xxx
If xxx is the string yes then the use is confirmed and the authentication will proceed. Otherwise, it fails.
Confirm is exclusive open and can only be opened by a process with the same user id as factotum.
needkey tag=tagno <key template>
It is up to the reader to then query the user for any missing fields, write the key tuple into the ctl file, and then reply by writing into the needkey file the string:
tag=tagno
Needkey is exclusive open and can only be opened by a process with the same user id as factotum.
The RPC protocol is normally embodied by one of the routines in auth(2). We describe it here should anyone want to extend the library.
An RPC consists of writing a request message to rpc followed by reading a reply message back. RPC's are strictly ordered; requests and replies of different RPC's cannot be interleaved. Messages consist of a verb, a single space, and data. The data format depends on the verb. The request verbs are:
9srv Manual Collection/plan9/factotum(4) | Rev: Sat Mar 08 20:41:19 GMT 2008 |