Add an internal-representation no-op function.
[u/mdw/catacomb] / pixie.1
CommitLineData
d92b3cee 1.\" -*-nroff-*-
2.de hP
3.IP
4.ft B
5\h'-\w'\\$1\ 'u'\\$1\ \c
6.ft P
7..
8.ie t .ds o \(bu
9.el .ds o o
10.
d07dfe80 11.TH pixie 1 "14 October 1999" "Straylight/Edgeware" "Catacomb cryptographic library"
d92b3cee 12.SH "NAME"
13pixie \- Catacomb passphrase pixie
14.SH "SYNOPSIS"
15.B pixie
16.RB [ \-qvfidl ]
17.RB [ \-c
18.IR command ]
19.RB [ \-t
20.IR timeout ]
21.RB [ \-s
22.IR socket ]
23.br
24.B pixie
25.RB [ \-s
26.IR socket ]
27.B \-C
28.RI [ "request args" ...]
29.SH "DESCRIPTION"
30The passphrase pixie manages passphrases. When it starts up, it creates
31a Unix-domain socket in a private directory. Clients may connect to it
32and request named passphrases: if the passphrase is known, the pixie
33returns it; otherwise the pixie may (configurably) either return a
34failure code to the client or attempt to prompt the user itself. In the
35former case, the client program will inform the pixie of the selected
36passphrase; in both cases, the passphrase will be remembered for later
37use.
38.PP
39Passphrases which have been stored for a long time without being used
40are removed from memory. On systems which support it, the passphrase
41pixie uses locked memory to prevent sensitive information from being
42swapped out by the operating system.
43.\"
44.SS "Command-line options"
45The
46.B pixie
47program understands the following command-line options:
48.TP
49.B "\-h, \-\-help"
50Prints a relatively comprehensive help message, and exit successfully.
51.TP
52.B "\-V, \-\-version"
53Print the pixie's version number and exit successfully.
54.TP
55.B "\-u, \-\-usage"
56Print a terse usage summary and exit successfully.
57.TP
58.B "\-C, \-\-client"
59Connect to a running pixie as a client. If command-line arguments are
60supplied, they are concatenated with spaces between them and submitted
61to the pixie as a request; a reply is read from the pixie and printed
62on stdout. If no command-line arguments are given, requestss are read
63interactively from stdin and sent to the pixie; the pixie's responses
64are printed on stdout.
65.TP
66.B "\-q, \-\-quiet"
67Causes the pixie to emit fewer log messages.
68.TP
69.B "\-v, \-\-verbose"
70Causes the pixie to emit more verbose log messages.
71.TP
72.BI "\-s, \-\-socket=" socket
73Uses
74.I socket
75as the name of the Unix-domain socket. If running as a client, this is
76the socket to which a connection is made. If running as a server, and
77the socket already exists, the pixie currently listening on the socket
78is told to quit.
79.TP
80.BI "\-c, \-\-command=" command
81Specifies a shell command to be run by the pixie when an unknown
82passphrase is requested by a client.
83.TP
84.BI "\-f, \-\-fetch"
85If an unknown passphrase is requested by a client, the pixie should
86attempt to read a passphrase itself rather than returning an error code.
87.TP
88.BI "\-t, \-\-timeout=" timeout
89Sets a timeout for the user's passphrase. The timeout is, by default,
90in seconds, although a suffix
91.RB ` m ',
92.RB ` h '
93or
94.RB ` d '
95can be added to specify minutes, hours or days respectively. A timeout
96of zero means that the pixie will never time out a passphrase. The
2b511ad9 97default is to time out a passphrase after 15 minutes.
d92b3cee 98.TP
99.B "\-d, \-\-daemon"
100Fork into the background and disassociate from the terminal after
101initializing.
102.TP
103.B "\-l, \-\-syslog"
104Send log messages to the syslog rather than stderr.
105.\"
106.SS "Memory management"
107During initialization, the pixie attempts to allocate a block of memory
108from the kernel and protect it against being swapped to disk. On most
109systems, this requires that the pixie start with root privileges,
110although it will drop them as soon as it can (before parsing
111command-line options).
112.PP
113The locked memory is used for all of the passphrases which the pixie
114stores, and for the buffers used to hold requests from clients.
115.\"
116.SS "The pixie socket"
117Communication with the passphrase pixie is performed over a Unix-domain
118socket.
119.PP
120If no socket name is specified on the command line, the pixie reads a
121default from the environment variable
122.BR CATACOMB_PIXIE_SOCKET ;
123if that's not set, a default of
124.RB ` %h/.catacomb/pixie '
125is used.
126.PP
127The socket name may contain substitution directives
128.RB ` %u '
129and
130.RB ` %h ',
131which are replaced by the current user's name and home directory
132respectively.
133.PP
134If
135.B pixie
136is running as a client, it will just attempt to connect to the socket.
137If this fails, it reports an error and exits. The remainder of this
138section deals only with the behaviour of the pixie as a server.
139.PP
140If the socket name has the form
141.IB dir / name
142then the pixie will check that
143.I dir
144is a directory, creating it if it doesn't exist, and that it is not
145readable or writable by anyone other than its owner.
146.PP
147It then attempts to create the socket, giving read and write permissions
148only to its owner. If the attempt succeeds, the pixie's initialization
149is complete.
150.PP
151If the attempt failed because a file with the required name already
152exists and is not a socket, the pixie reports an error and exits. If
153there's already a socket with that name, the pixie connects to it, sends
154a
155.B QUIT
156request to the server, waits for a second and retries. If the
157connection attempt fails because there's nobody listening, the pixie
158assumes that the socket is stale, deletes it, and tries again.
159.\"
160.SS "Pixie protocol"
161The protocol used by the pixie is fairly straightforward.
162.PP
163Passphrases are known by textual
164.I tags
165which are assigned by the client. A tag must not contain whitespace
166characters. It's conventional for the tag to be lowercase or mostly
167lowercase, and for multiple words to be joined by dashes.
168.PP
169The pixie's responses always have one of the following forms:
170.TP
171.BR OK " [\fIphrase\fR]"
172The request completed successfully. If the request was
173.B PASS
174or
175.BR VERIFY ,
176the response contains the passphrase.
177.TP
178.B MISSING
179The passphrase requested is not known. The client should request the
180passphrase from the user itself, and then inform the pixie using the
181.B SET
182request.
183.TP
184.BI FAIL " error"
185The request failed. The
186.I error
187is a human-readable explanation of what went wrong.
188.TP
189.BI INFO " message"
190Reports a human-readable informational message. Processing of the
191request is not complete: further responses will follow.
192.TP
193.BI ITEM " tag expires"
194Reports a passphrase as part of the response to a
195.B LIST
196request. One
197.B ITEM
198response is given for each passphrase currently known. The
199.I tag
200field names the passphrase tag, and the
201.I expires
202field gives the number of seconds until the passphrase will expire.
203Processing of the request is not complete: further responses will
204follow.
205.PP
206The requests available are as follows:
207.TP
208.B HELP
209Returns brief help on the available protocol requests.
210.TP
211.B LIST
212Returns a list of the currently-known passphrases and their expiry
213information.
214.TP
215.BI PASS " tag \fR[\fIexpire\fR]"
216Returns the passphrase named
217.IR tag .
218If the passphrase is unknown, and the pixie fetches it, it should expire
219after the timeout given by
220.IR expire ,
221using the same syntax as the
222.B \-t
223command-line option.
224.TP
2b511ad9 225.BI VERIFY " tag \fR[\fIexpire\fR]"
d92b3cee 226Requests a new passphrase named
227.IR tag .
228If the pixie is capable of fetching passphrases, it should ask the user
229for confirmation to guard against typos. Otherwise this is the same as
230the
231.B PASS
232request.
233.TP
2b511ad9 234.BI SET " tag \fR[\fIexpire\fR] " \-\- " phrase"
d92b3cee 235Sets the value of the passphrase named
236.I tag
237to be
238.IR phrase ,
239optionally setting its expiry time to
240.IR expire .
241This will usually be a follow-up to a
242.B MISSING
243response. If a passphrase with the same tag is already known, it is
244removed.
245.TP
246.BR FLUSH " [\fItag\fR]"
247If a
248.I tag
249is given, flush that passphrase from memory. Otherwise flush
250.I all
251passphrases from memory.
252.TP
253.B QUIT
254Asks the pixie to quit.
255.PP
256Pixie requests are not case sensitive, in order to make interactive use
257easier. The responses are guaranteed to be returned in uppercase,
258however.
259.\"
260.SS "Specifying commands"
261If the pixie is given a
262.B \-c
263option, it will use the argument as a shell command in order to request
264passphrases from the user. Before execution, the pixie will perform
265some substitutions on the command string:
266.TP
267.B %m
268One of
269.RB ` Passphrase ',
270.RB ` "New passphrase" ',
271or
272.RB ` "Verify passphrase" '
273as appropriate.
274.TP
275.B %t
276The tag of the passphrase being requested.
277.PP
278The shell command is expected to write the passphrase to its standard
279output, optionally followed by a newline, and exit with status 0. If it
280returns some other exit status, the pixie will assume that it failed and
281ignore its output.
282.SH "IMPORTANT SECURITY NOTE"
283Don't use this software on a machine with a hostile admin. You will
284lose. Any machine with hostile administration must be automatically
285assumed hostile. Never type a passphrase into a hostile machine. Don't
286sent a passphrase over a hostile or potentially hostile network. Don't
287do anything else stupid.
288.SH "OTHER CAVEATS"
289The pixie's preinitialization checking doesn't do a thorough audit of a
2b511ad9 290directory, in the way that, say,
d92b3cee 291.BR chkpath (1)
292does. It's your responsibility to make sure that the full path is
293relatively safe.
294.PP
295It's possible, though unlikely, that there's a security hole in the part
296of the
297.B pixie
298program which can run with setuid privileges. In this case, remove
299setuid privileges immediately \- the program runs quite happily without,
300except that it might not be able to lock pages into memory.
301.SH "ACKNOWLEDGEMENTS"
302The original passphrase pixie was written by Ian Jackson as part of his
303.B auto-pgp
304package. This version of the pixie is major evolution of one I wrote
305for PGP which incorporated the improvements over the original which were
306noted in the
307.B auto-pgp
308documentation.
309.SH "AUTHOR"
310Mark Wooding, <mdw@nsict.org>