discover/discover-server: Restrict clients based on uid If crypt support is enabled restrict what actions clients can perform by default. Initial authorisation is set at connection time; clients running as root are unrestricted, anything else runs as restricted until it makes an authentication to pb-discover. Unprivileged clients may only perform the following actions: - Boot the default boot option. - Cancel the autoboot timeout. - Make an authentication request. If a group named "petitgroup" exists then the socket permissions are also modified so that only clients running as root or in that group may connect to the socket. The user-event socket is only usable by root since the two main usecases are by utilities called by pb-discover or by a user in the shell who will need to su to root anyway. Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
discover: Handle and track plugin_options Track plugin_options in the device_handler. Plugins can be added with device_handler_add_plugin_option() and accessed via device_handler_get_plugin(). Extend discover_server to support the new 'add' and 'remove' pb-protocol actions and advertise new plugins to connecting clients. Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
types: shorten boot_status definitions struct boot_status is a bit misnamed; we report status on things that aren't just the boot status (eg, discovery). This change refactors struct boot_status into just struct status. We give the type enum a name, and shorten the enum values to suit. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
config: Implement config messages On client connect, send a PB_PROTOCOL_ACTION_CONFIG message. Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Add system info messages Add a little infrastructure for communicating information about the system to the petitboot UIs. We just send some identifying info (type and identifier), as well as the interfaces. Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
discover: Add discover_server_notify_boot_status Add a function to the server to notify clients of boot status updates. Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
protocol: Separate device add from boot-option add messages We want to cater for situations where boot options may be discovered some time after we get notificiation about devices. For instance, discovering boot options from DHCP configuration parameters. In this case, we'll need to notify UIs of boot options appear some time after the device (and/or other boot options on the same device) has appeared. This change adds a new protocol message type, PB_PROTOCOL_ACTION_BOOT_OPTION_ADD. We also rename PB_PROTOCOL_ACTION_ADD to make it clear that it is just for devices. The discover server is updated to send boot option add events at device discover time, but we are now able to decouple this later. We also update the clients to handle the boot option add events separately. Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
waiter: Don't rely on global variables to keep waiter state Rather than defining the set of waiters (and pollfds) in waiter.c, add a struct waitset to contain these. A waitset is created with waitset_create, which is passed to the waiter_* functions. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Geoff Levand <geoff@infradead.org>
Hook up parsers to device discovery Iterate the parsers from the device handler on an add event. Initial change to just the kboot parser. Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Create device-handler for managing registered devices Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Initial support for multiple UIs Move the device discovery code from separate udev helpers to a single process to listen on two sockets: one SOCK_DGRAM for incoming udev events, and one SOCK_STREAM for UIs to connect. Initial support for client/server infrastructure, still need to wire-up the udev messages. Signed-off-by: Jeremy Kerr <jk@ozlabs.org>