Replying to [ticket:103 spstarr]:

I think we should clarify why FESCo permission is required.

If it is due to potential security issues with default configurations or other reasons vs just saying you must ask FESCo for permission doesn't explain the reason.

A little clarification would help.

From my first reason, I assume "I can't package a .socket file because FESCo says so". Even if I might eventually deduce the reason.

It might make sense for FESCo to determine a list of safe packages to enable socket activation just as done with http://fedoraproject.org/wiki/Starting_services_by_default

Socket activation is by definition autostarting of the service. FPC determined that there is no difference between setting a package to automatically start if the trigger is booting and automatically autostart if the trigger is that something requests the socket that the service is for.

We could change the following section to be a bit more clear about this, I suppose:

"""
In practical terms this means if the upstream tarball ships with a socket file you need to contact FESCo to get permission to enable your service on boot.
"""

to:

"""
In practical terms, this means that we treat socket activatable services as allowed to start on boot. If the upstream tarball ships with a .socket file you need to contact FESCo to get permission to enable your service on boot.
"""

Reading the guidelines, we probably should add a similar phrase to the DBus activatable section as well although this may need more discussion as its not an area that we were aware of before the systemd update and therefore people may have been autostarting system daemons via dbus and they'll now need to be enumerated and granted permission.

There is another security problem with socket-activated services. Systemd does not limit recording of service failures which can lead to remote DOS by memory exhaustion. Lennart recommends to ignore return code of such services by prepending hyphen character to ExecStart value. See [https://bugzilla.redhat.com/show_bug.cgi?id=739538 bug report #739538].

Because Lennart is not going to prevent DOS on systemd site, I recommend to emphasis this problem in packaging guidelines and recommend packagers to ignore exit code in socket-actived service files.

Replying to [comment:3 ppisar]:

There is another security problem with socket-activated services. Systemd does not limit recording of service failures which can lead to remote DOS by memory exhaustion.

To clarify, this applies only to services instantiated dynamically from service templates, not to all socket-activated services.

Just updating this a bit -- we've discussed this in several of the FPC meetings and decided that some of the things we were told about activation and enabling are not correct. We've asked Lennart to come up with some additional wording about this but he hasn't gotten back to us yet.

Replying to [comment:5 toshio]:

Just updating this a bit -- we've discussed this in several of the FPC meetings and decided that some of the things we were told about activation and enabling are not correct. We've asked Lennart to come up with some additional wording about this but he hasn't gotten back to us yet.

Oh, uh? Did I miss something? I am happy to provide you with additional wording, but I somehow missed that. Can you elaborate? I'll then answer here.

Humpf, and how can I add myself to the CC here? I seem to lack the privs. So if somebody coments here, please notify me by mail (lennart at poettering net). Thanks!

BTW, I have now opened another bug with my thoughts on this:

https://fedorahosted.org/fpc/ticket/208

(sorry for opening another bug about this, I totally forgot that this one already existed.)