On Mon, 12 Dec 2016, Lennart Poettering wrote:
Note that I wonder if restricting address families really belongs in
systemd. Why isnt this a libcap-ng capability? That way my software
can support this without depending on systemd.
hu?
libcap-ng is a library to manage Linux process capabilities.
RestrictAddressFamilies= is a unit file setting, all you have to do
enable it in the unit files of your choice, and the service it runs
then loses access to a specific AF_xyz family (or all but a specific
one). It's implementation is based on Linux seccomp, a kernel facility
entirely unrelated to Linux process capabilities.
Oh, I didn't realise it used seccomp. Never mind then. Those who
implemented something using libseccomp I guess could do this also
independently of systemd.
And there's no talk of having to "depend" on systemd for this to
work. If you ship a systemd unit file in your package (and, quite
frankly you have to if your package contains a service of some kind,
this is Fedora after all), then all you need to do is add a line
RestrictAddressFamilies= to it.
I was talking with my (libreswan) upstream hat on. In general, we try
and support things independent of kernel or OS.
Ideally, you'd ship such a unit file upstream. But if you don't want
your stuff tainted by the horrible idea of shipping systemd unit files
upstream, then it's totally enough to make this change downstream in
the RPM.
Yes, we auto-detect systemd and ship service fils there too. And even
support systemd native things like sd_notify() when available :P
Of course, you can also set up seccomp filters yourself, in your
daemon, in C code, by using libseccomp. It's great if you do
We do.
that's totally possible, and can be functionality-wise entirely
equivalent. The only difference is: systemd makes all of this
trivially easy to use, by making this a single-line change in a unit
file without involving C hacking.
For us (libreswan) it probably makes less sense to restrict address
family in the daemon. Our daemon just listens to UDP 500/4500, so it
would never be affected by any other kind of address families.
Paul
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
