Dimitrios Chr. Ioannidis:
A quick search reveals the following.
>
> I've a software that use libuuid. Until now, the uuidd had the
> ability to start on-demand the uuidd if the later, quotting "...
> setuid to an unprivileged user (e.g. uuidd:uuidd)".
>
> After that commit, i'm forced to use systemd, if i don't want to
> start uuidd from the beginning. That's new for me...
Aside from the security implications of doing things the old way, which
Christian Seiler touched upon, you are not forced to use systemd. You
are forced to use a service management system that is capable of
listening on AF_LOCAL sockets and starting up daemon processes using the
systemd socket-file-descriptor transfer protocol, a subtly different
thing. As I've pointed out, with the local-stream-socket-listen tool
from nosh, one can write a run script that one can use under nosh,
daemontools, daemontools-encore, freedt, runit, or s6, or an rc.main
script that one can use under perp. That's a choice of 7 service
management systems, for starters. util-linux is not forcing you to use
systemd. The only limitations that util-linux is imposing are the
limitations that uuidd only speaks the systemd socket-file-descriptor
transfer protocol, and that it only works in listen-only mode. Yet
there are already service management tools other than systemd that speak
that protocol and allow listen-only mode. One of them even comes with a
tool that can write a run script for you, if you have the util-linux
socket and service units to hand.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54554f8e.4080...@ntlworld.com
