Free all clients in the child process after pth_fork().
[pwmd.git] / COMMANDS
blob41f9a1792b87559c817f1e10767dd8fd5c136216
1 The server uses a protocol provided by libassuan to communicate with a client.
2 An OK response is returned when a command succeeds or ERR along with an error
3 code and description, if not. When a command requests data for retrieval
4 (e.g., GET) the output is prefixed with D then a single SPACE then the actual
5 data followed by an OK response if successful. Read the libassuan docs for
6 more info about the protocol.
9 PROTOCOL COMMANDS
10 -----------------
12 OPEN <filename> [<key>]
13     Opens <filename> using <key>. If file is not found on the file-system, then
14     a new document will be created. If the file is found, it is looked for in
15     the file cache for an existing key. When found, the existing key will be
16     used for decryption. When not found, pinentry(1) will be used to retrieve
17     the key (see OPTIONS below). You can also open another file using the
18     same connection. When using an empty key and you want to avoid the
19     pinentry dialog, set PINENTRY to 0 (see OPTIONS below).
22 SAVE [<key>]
23     Writes the XML document to disk. The file written to is the file that was
24     opened using the OPEN command. If <key> is not specified then the
25     currently cached key will be used. If the file is a new file or the file
26     isn't found in the file cache, <key> may be used. If <key> is not
27     specified then pinentry(1) will be used to retrieve the key (see OPTIONS
28     below). When using an empty key and you want to avoid the pinentry dialog,
29     set PINENTRY to 0 (see OPTIONS below).
31     When the SAVE command is sent and a key is found in the file cache, the
32     cached key will be used. To reset the key to a new value, send the
33     CLEARCACHE command followed by the filename, then send the SAVE command to
34     enter a new key.
37 ISCACHED <filename>
38     An OK response is returned if the specified file is in the file cache.
41 CLEARCACHE [<filename>]
42     Clears a file cache entry. This will forget the timeout and key for all or
43     the specified file.
46 CACHETIMEOUT <seconds> <filename>
47     Specify the number of seconds the specified file will be cached. -1 will
48     keep the cache entry forever, 0 will require the key each time the OPEN or
49     SAVE commands are used. Also see the "cache_timeout" configuration option.
52 LIST [[!]element[<TAB>[!]element[...]]]
53     If no element path is given then a list of root elements is returned with
54     the data response code. If given, then all reachable elements for the
55     specified element path are returned. Each element in the path is prefixed
56     with the literal '!' character when the element contains no "target"
57     attribute (See THE TARGET ATTRIBUTE below).
60 REALPATH [!]element[<TAB>[!]element[...]]
61     Resolves all "target" attributes of the specified element path and returns
62     the result with a data response.
65 STORE [!]element[[<TAB>[!]element[...]]<TAB>[content]]
66     Creates a new element tree or modifies the content of an existing element
67     path. If only a single element is specified, a new root element is
68     created. Otherwise, elements are TAB delimited and the content will be set
69     to the last TAB delimited argument. If no content is specified after the
70     last TAB then the content for the last specified element will be removed
71     or the content will be empty when creating a new element.
72     
73     The only restriction of element names is that they not begin with a
74     punctuation character (the literal '!' character is an exception) or digit
75     and not contain any whitespace. There is no whitespace between the TAB
76     delimited elements. It is recommended that the value be base 64 encoded to
77     prevent libXML and pwmd parsing errors.
78     
79     PWMD reads the element path from the client via the Assuan INQUIRE
80     protocol response. The STORE command is sent by itself without arguments,
81     then the server responds with INQUIRE. The client then sends the element
82     path prefixed by a "D " data response. When finished, the client
83     sends "END" on an empty line. This is needed so an element path and value
84     can be more than 1000 bytes long, the Assuan protocol line limit.
87 DELETE [!]element[<TAB>[!]element[...]]
88     Removes an element tree from the specified element path.
91 GET [!]element[<TAB>[!]element[...]]
92     Retrieves the content of the specified element path. The data is returned
93     with a data response.
96 ATTR SET|GET|DELETE|LIST [<attribute>] [!]<arg1> [!][arg2]
97     ATTR SET attribute [!]element[<TAB>[!]element[...]] attribute_value
98         Stores or updates an attribute value to an element path.
100     ATTR DELETE attribute [!]element[<TAB>[!]element[...]]
101         Removes an attribute from an element path.
103     ATTR LIST [!]element[<TAB>[!]element[...]]
104         Gets a list of attributes from an element path.
106     ATTR GET attribute [!]element[<TAB>[!]element[...]]
107         Gets the value of an attribute from an element path.
109     The "name" attribute (case sensitive) cannot be removed with ATTR DELETE
110     if the element path is only a root element. Although it can be SET to
111     change the root element name.
113     Also see THE TARGET ATTRIBUTE below.
116 DUMP
117     Shows the in memory XML document with indenting.
120 GETCONFIG <parameter>
121     Returns the value of a pwmd configuration variable with a data response.
122     If no file is open then the default value will be returned. The "key" and
123     "key_file" variables are ignored.
126 OPTION NAME=VALUE
127     Sets an option NAME to VALUE. See OPTIONS below.
131     Closes the connection. Use the SAVE command before this command as any
132     changes will be lost.
135 If a command fails then the ERR response is returned followed by a protocol
136 error code and description. See src/pwmd_error.h or libpwmd/libpwmd.h for
137 error codes.
140 OPTIONS
141 -------
142 Commands that require a key that is neither cached or specified will use
143 pinentry(1) to retrieve the key. Pinentry options can be set with the OPTION
144 command followed by the option name and value. Below are the available
145 pinentry options:
147     NAME       VALUE      Description
148     ---------|----------|----------------------------------------------------
149     PINENTRY  0|1        When 0, disable use of pinentry. The default is 1.
150     PATH      <string>   Full path to the pinentry binary. The default is
151                          specified at compile time (/usr/bin/pinentry).
152     TTYNAME   <string>   Same as the --ttyname option to pinentry(1).
153     TTYTYPE   <string>   Same as the --ttytype option to pinentry(1).
154     DISPLAY   <string>   Same as the --display option to pinentry(1).
155     TITLE     <string>   Sets the title string of the dialog.
156     PROMPT    <string>   Sets the prompt string of the dialog.
157     DESC      <string>   Sets the error or description string of the dialog.
159 When pinentry is used with the SAVE command the key will be asked for
160 confirmation. If the confirmation fails, the process is started over again
161 until either the keys match or until Cancel is selected. The OPEN command will
162 only ask for the key once without retrying on failure. It is up to the client
163 to retry the OPEN command. Empty keys are allowed.
165 There is also a CLIENT option that contains other sub-options. The format is
166 OPTION CLIENT NAME=VALUE, where NAME is one of:
168     NAME       VALUE      Description
169     ---------|----------|----------------------------------------------------
170     NAME      <string>   Associates the thread ID of the connection with the
171                          specified textual representation. Useful for
172                          debugging log messages.
175 STATUS MESSAGES
176 ---------------
177 Some commands send a status message to the client when successful or as a
178 progress indicator. Status messages begin with a KEYWORD (see below) followed
179 by the status description. What messages are sent, and how often, depend on
180 configuration settings:
182     COMMAND             KEYWORD
183     --------------------------------
184     OPEN                DECRYPT
185                         DECOMPRESS
186                         CACHE
187                         LOCKED
189     SAVE                COMPRESS
190                         ENCRYPT
191                         CACHE
192                         LOCKED
194     CLEARCACHE          CACHE
195                         LOCKED
197     CACHETIMEOUT        CACHE
198                         LOCKED
200     ISCACHED            LOCKED
203     KEYWORD             OUTPUT FORMAT
204     ---------------------------------
205     CACHE               <slots used> <slots available>
206     ENCRYPT             <iterations so far>
207     DECRYPT             <iterations so far>
208     COMPRESS            <bytes so far> <total bytes>
209     DECOMPRESS          <bytes so far> <total bytes>
210     LOCKED              When another thread owns the file/key cache lock,
211                         this is sent once and the thread blocks until the
212                         lock can be obtained and the command completes.
213     KEEPALIVE           Sent the after every configured amount of seconds.
214                         This lets the client know that the connection is still
215                         active for commands that take a while to complete.
218 THE TARGET ATTRIBUTE
219 --------------------
220 There is a special attribute "target" (case sensitive) that can be set with
221 ATTR SET. The value of this attribute is an element path somewhere else in the
222 XML document:
224 ATTR SET target [!]element[<TAB>[!]element[..]] [!]element[<TAB>[!]element[..]]
225                    arg1^^^^^^^^^^^^^^^^^^^^^^^^    arg2^^^^^^^^^^^^^^^^^^^^^^^^
227 If the element path of the "target" attribute (arg1) doesn't exist, it is
228 created. This is the only time the ATTR command will create elements.
230 When a protocol command requests <arg1> as the element path, the remaining
231 elements after the element with the "target" attribute will be appended to
232 <arg2>. This is useful if you have elements that share the same data. If the
233 target is modified, the other elements "pointing" to the target will have the
234 same content. To get the real or literal element and ignore any "target"
235 attributes, prefix an element with a '!' character. Here's an example:
237     C> STORE
238     S> INQUIRE STORE
239     C> D host1<TAB>username<TAB>original username
240     C> END
241     S> OK
242     C> STORE
243     S> INQUIRE STORE
244     C> D host2<TAB>smtp<TAB>username<TAB>someuser
245     C> END
246     S> OK
247     C> ATTR SET target host1<TAB>username host2<TAB>smtp<TAB>username
248     S> OK
250 Now host1's "target" attribute will be used:
252     C> GET host1<TAB>username
253     S> D someuser
254     S> OK
256 If you want host1's username, prefix the element of the "target" attribute
257 with a '!':
259     C> GET host1<TAB>!username
260     S> D original username
261     S> OK
263 The target value (arg2) element can also have a "target" attribute:
265     C> ATTR SET target new_account host1
266     S> OK
267     C> GET new_account<TAB>username
268     S> D someuser
269     S> OK
271 The value of the "target" attribute may also be prefixed with a '!' to set the
272 target to the actual element path and not a target of the element path:
274     C> ATTR DELETE target !new_account
275     S> OK
276     C> ATTR SET target new_account<TAB>username host1<TAB>!username
277     S> OK
278     C> GET new_account<TAB>username
279     S> D original username
280     S> OK
282 The "target" attribute is considered for all commands that support an element
283 path. If the target element has been renamed or deleted afterwards, the
284 command will fail.
286 Clients should be careful of creating target loops. See the "recursion_depth"
287 configuration parameter for details.
290 XML DOCUMENT STRUCTURE
291 ----------------------
292 When importing an XML data file with the -I command line option, the document
293 should have the following DTD:
295     <?xml version="1.0"?>
296     <!DOCTYPE accounts [
297     <!ELEMENT accounts (account*)>
298     <!ATTLIST account name CDATA #REQUIRED>
299     ]>
301 "accounts" is the document root element while each root element mentioned in
302 the protocol commands use the "account" element. So if you have a root element
303 "isp" to be shown with the LIST command ("LIST isp"), the document structure
304 looks like this:
306     <accounts>
307         <account name="isp">
308         [...]
309         </account>
310     </accounts>
312 The DUMP command can be useful to show the current document structure.
315 DESIGN
316 ------
317 The key cache is protected with a mutex and is locked with each access. Each
318 cache entry also contains a mutex for the opened file and a reference count
319 which is adjusted each time a client connects or disconnects. This allows
320 client A to issue commands that aren't related to the file opened by client B.
321 The refcount is needed to prevent the mutex being overwritten when the entry
322 needs to be reset (CACHETIMEOUT for example) and there are any client
323 connected.
325 The client_thread() uses an event to wait for the client FD to become ready
326 for reading. When ready, it uses the libassuan assuan_process_next() function
327 to prevent blocking. This allows for the keepalive_thread() and any signals
328 send to client_thread() to continue to work and lets the Pth scheduler let
329 other (client) threads do their work too.
331 The cleanup_thread() is a loop that sleeps at some interval and is responsible
332 for freeing the resources of the client after the associated client_thread()
333 terminates or exits. How it determines if the client exited is done with the
334 PTH_UNTIL_TID_DEAD event; it checks a list of recorded connections for that
335 event.
337 When a key is required for the OPEN or SAVE commands, and OPTION PINENTRY=1,
338 pinentry(1) is used to retrieve the key. This is done by creating a pipe()
339 with the client_thread(), then pth_fork()'s the pinentry process which will
340 write the key or error to the pipe that client_thread() will read from. After
341 the read, the pinentry should have exited and client_thread() calls the
342 finalization function for the command that used pinentry.
345            -------------       ---------------
346  ----------[server_loop]-_-_-_-[socket_thread]
347  |         -------------       ---------------
348  |     not joinable :                | accept()
349  |  ---------------------     ---------------
350  |  [adjust_timer_thread]     [client_thread]<------------=====
351  |  ---------------------     ---------------   |   |    |    =
352  |                              :   | |    |    |   |    |    =
353  |---|                          :   | |    |    |   |    |    =
354      |                          :   | |    |    |   |    |    =
355  ----------------               :   | |    |    |   |    |    =
356  [cleanup_thread]       :::::::::   | |    |    |   |    |    =
357  ----------------       :           | |  ---------  |    |    =
358        | pth_cancel()   :           | |  [command]  |    |    =
359        |        ------------------  | |  ---------  |    |    = pipe()
360        |--------[keepalive_thread]  | |    |   |    |    |    =
361                 ------------------  | |    |  ---------  |    =
362                                     | |    |  [inquire]  |    =
363                                     | |    |  ---------  |    =
364                                     | |    |    -----------   =
365                                     | |    |----[OPEN/SAVE]   = 
366                                     | |         -----------   =
367                           --------------------       : fork() =
368                           [ command finalize ]   ----------   =
369                           --------------------   [pinentry]====
370                                                  ----------
373 Questions, bugs or feature requests can be sent to
374 Ben Kibbey <bjk@luxsci.net>.