localservice.html (5914B)
1 <html> 2 <head> 3 <meta name="viewport" content="width=device-width, initial-scale=1.0" /> 4 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 5 <meta http-equiv="Content-Language" content="en" /> 6 <title>s6: what is a local service</title> 7 <meta name="Description" content="s6: what is a local service" /> 8 <meta name="Keywords" content="s6 local service s6-ipcserver" /> 9 <!-- <link rel="stylesheet" type="text/css" href="//skarnet.org/default.css" /> --> 10 </head> 11 <body> 12 13 <p> 14 <a href="index.html">s6</a><br /> 15 <a href="//skarnet.org/software/">Software</a><br /> 16 <a href="//skarnet.org/">skarnet.org</a> 17 </p> 18 19 <h1> Local services </h1> 20 21 <p> 22 A <em>local service</em> is a daemon that listens to incoming connections 23 on a Unix domain socket. Clients of the service are programs connecting to 24 this socket: the daemon performs operations on their behalf. 25 </p> 26 27 <p> 28 The service is called <em>local</em> because it is not accessible to 29 clients from the network. 30 </p> 31 32 <p> 33 A widely known example of a local service is the <tt>syslogd</tt> daemon. 34 On most implementations, it listens to the <tt>/dev/log</tt> socket. 35 Its clients connect to it and send their logs via the socket. The 36 <tt>openlog()</tt> function is just a wrapper arround the <tt>connect()</tt> 37 system call, the <tt>syslog()</tt> function a wrapper around <tt>write()</tt>, 38 and so on. 39 </p> 40 41 <h2> Benefits </h2> 42 43 <h3> Privileges </h3> 44 45 <p> 46 The most important benefit of a local service is that it permits 47 <strong>controlled privilege gains without using setuid programs</strong>. 48 The daemon is run as user S; a client running as user C and connecting to 49 the daemon asks it to perform operations: those will be done as user S. 50 </p> 51 52 <p> 53 Standard Unix permissions on the listening socket can be used to implement 54 some basic access control: to restrict access to clients belonging to group 55 G, change the socket to user S and group G, and give it 0420 permissions. 56 This is functionally equivalent to the basic access control for setuid 57 programs: a program having user S, group G and permissions 4750 will be 58 executable by group G and run with S rights. 59 </p> 60 61 <p> 62 But modern systems implement the 63 <a href="https://web.archive.org/web/20210504203038/https://www.superscript.com/ucspi-ipc/getpeereid.html">getpeereid()</a> 64 system call or library function. This function allows the server to know the 65 client's credentials: so fine-grained access control is possible. On those 66 systems, <strong>local services can do as much authentication as setuid programs, 67 in a much more controlled environment</strong>. 68 </p> 69 70 <h3> fd-passing </h3> 71 72 <p> 73 The most obvious difference between a local service and a network service 74 is that a local service does not serve network clients. But local services 75 have another nice perk: while network services usually only provide you 76 with a single channel (a TCP or UDP socket) of communication between the 77 client and the server, forcing you to multiplex your data into that 78 channel, local services allow you to have as many 79 communication channels as you want. 80 </p> 81 82 <p> 83 (The SCTP transport layer provides a way for network services to use 84 several communication channels. Unfortunately, it is not widely deployed 85 yet, and a lot of network services still depend on TCP.) 86 </p> 87 88 <p> 89 The <em>fd-passing</em> mechanism is Unix domain socket black magic 90 that allows one peer of the socket to send open file descriptors to 91 the other peer. So, if the server opens a pipe and sends one end of 92 this pipe to a client via this mechanism, there is effectively a 93 socket <em>and</em> a pipe between the client and the server. 94 </p> 95 96 <h2> UCSPI </h2> 97 98 <p> 99 The <a href="https://cr.yp.to/proto/ucspi.txt">UCSPI</a> protocol 100 is an easy way of abstracting clients and servers from the network. 101 A server written as a UCSPI server, just as it can be run 102 under inetd or 103 <a href="//skarnet.org/software/s6-networking/s6-tcpserver.html">s6-tcpserver</a>, 104 can be run under 105 <a href="s6-ipcserver.html">s6-ipcserver</a>: choose a socket 106 location and you have a local service. 107 </p> 108 109 <p> 110 Fine-grained access control can be added by inserting 111 <a href="s6-ipcserver-access.html">s6-ipcserver-access</a> in 112 your server command line after s6-ipcserver. 113 </p> 114 115 <p> 116 A client written as an UCSPI client, i.e. assuming it has descriptor 117 6 (resp. 7) open and reading from (resp. writing to) the server socket, 118 can be run under <a href="s6-ipcclient.html">s6-ipcclient</a>. 119 </p> 120 121 <h2> Use in skarnet.org software </h2> 122 123 <p> 124 skarnet.org libraries often use a separate process to handle 125 asynchronicity and background work in a way that's invisible to 126 the user. Among them are: 127 </p> 128 129 <ul> 130 <li> <a href="libs6/s6-ftrigrd.html">s6-ftrigrd</a>, 131 managing the reception of notifications and only waking up the client process 132 when the notification pattern matches a regular expression. </li> 133 <li> <a href="libs6/s6lockd.html">s6lockd</a>, 134 handling time-constrained lock acquisition on client behalf. </li> 135 <li> <a href="//skarnet.org/software/s6-dns/skadns/skadnsd.html">skadnsd</a>, 136 performing asynchronous DNS queries and only waking up the client process 137 when an answer arrives. </li> 138 </ul> 139 140 <p> 141 Those processes are usually spawned from a client, via the corresponding 142 <tt>*_startf*()</tt> library call. But they can also be spawned from a 143 s6-ipcserver program in a local service configuration. In both cases, they 144 need an additional control channel to be passed from the server to 145 the client: the main socket is used for synchronous commands from the client 146 to the server and their answers, whereas the additional channel, which is 147 now implemented as a socket as well (but created by the server on-demand 148 and not bound to a local path), is used for asynchronous 149 notifications from the server to the client. The fd-passing mechanism 150 is used to transfer the additional channel from the server to the client. 151 </p> 152 153 </body> 154 </html>