RFC: [gssproxy] Improved systemd integration

[Alphix]

These patches improve the systemd integration and also hardens the systemd .service unit.

Lightly tested, so consider an RFC for now. I want some feedback if this is desirable before I spend more time on testing, etc.

[Alphix]

Some notes:

1. Could be further simplified if systemd support was made a hard dependency
2. There's compile warnings with or without these patches if systemd is not enabled
3. Documentation changes are probably a good idea if this PR is accepted (especially to mention that all RW data must be in certain locations due to the systemd protections and that it can be further restricted/unrestricted using systemd drop-ins)

[Alphix]

@simo5 not sure if you get notified about draft PRs, if not, ping :)

[simo5]

I get notified, but feel free to ping if I miss them, I sometimes get busy elsewhere and then forget to check back.

[simo5]

I think the first patch will break older systems. The systemd detection is complicated because older versions had a different package split, but I forgot the deatils and may well be wrong.

[Alphix]

I think the first patch will break older systems. The systemd detection is complicated because older versions had a different package split, but I forgot the deatils and may well be wrong.

I think you might be referring to systemd 209? That's covered in the patch message...that was when the libsystemd-*.so libraries were merged into libsystemd.so...and that was in 2014.

Or are you referring to something else?

[Alphix]

As a general concept I like this PR.

Good, do you want to keep the (incomplete, because there's no /etc/init.d/gssproxy file) support for non-systemd systems? Because if the answer is no, there's a whole bunch of code that can be simplified/removed....

[simo5]

I think the first patch will break older systems. The systemd detection is complicated because older versions had a different package split, but I forgot the deatils and may well be wrong.

I think you might be referring to systemd 209? That's covered in the patch message...that was when the libsystemd-*.so libraries were merged into libsystemd.so...and that was in 2014.

Or are you referring to something else?

I was, but if RHEL-8 is not affected I wthink we can definitely change it.

[simo5]

As a general concept I like this PR.

Good, do you want to keep the (incomplete, because there's no /etc/init.d/gssproxy file) support for non-systemd systems? Because if the answer is no, there's a whole bunch of code that can be simplified/removed....

I want to still make it possible to have this work w/o systemd, but I do not care for shipping init files myself.

[Alphix]

I think you might be referring to systemd 209?

I was, but if RHEL-8 is not affected I wthink we can definitely change it.

RHEL8 was (from what I've understood from a quick Google search) released in 2019 and uses systemd v239? If so, shouldn't be a problem...

[Alphix]

...do you want to keep the...support for non-systemd systems?...

I want to still make it possible to have this work w/o systemd, but I do not care for shipping init files myself.

Ok, good, then the current state should be fine...

[Alphix]

@simo5 : Ok, rebased version pushed, should address all feedback you've provided so far...by default, /tmp, /root, /home, /run/user and /var/gssproxy should now be read-writable to gssproxy. I've added a comment on how to further restrict this using a drop-in. Hopefully that can be reversed in the future (i.e. to make /tmp, /root, /home and /run/user RW access opt-in instead of opt-out).

[simo5]

Thanks looks good, therefore I marked it ready and merging