Bugzilla – Bug 860331
systemd unit files: have only cups.service enabled by default as systemd printing related unit
Last modified: 2014-01-30 08:13:31 UTC
It seems there is no bugzilla component for systemd related issues. Therefore I use the bugzilla component "Other". This is an enhancement request to provide a better out-of-the-box user experience for printing related services. During off-topic discussions in bnc#857372 "VUL-0: cups: cups.socket is listening on 0.0.0.0" it appeared that at least systemd's cups.socket does not work well. Furthermore there is bnc#795624 "CVE-2012-6094: systemd socket activation sometimes breaks cups printing" Both indicate that it is better to have at least systemd's cups.socket disabled by default or even completely removed. For all systemd unit files (except cups.service) that are somehow related to printing it should be carefully and thoroughly evaluated which one should be - enabled by default - disabled by default - completely removed On my current openSUSE 13.1 system I get at least those systemd unit files that are related to printing: ---------------------------------------------------------------------- # systemctl list-unit-files | egrep -i 'print|cups' cups.path configure-printer@.service cups.service cupsd.service cups.socket printer.target ---------------------------------------------------------------------- To avoid misunderstandings: I am only the messenger here. I have no knowledge how the systemd functionality works and/or how it is implemented in CUPS nor do I know how the systemd functionality for CUPS is meant to work (i.e. the policy behind how it should work). I can maintain the plain CUPS software but I cannot maintain the policy under what circumstances the cupsd should be enabled/disabled/started/stopped. For details see https://bugzilla.novell.com/show_bug.cgi?id=857372#c15 https://bugzilla.novell.com/show_bug.cgi?id=857372#c19
I have a better idea: According to how I understand it, it is basically a security issue to define under what circumstances a service should be enabled/disabled/started/stopped in what particular way (e.g. on a home-user system versus on an enterprise system or depending on whatever kind of product openSUSE/SLES/SLED or depending on whatever else...). I change the bugzilla component to "Security".
thanks for creating this enhancement request .. i'd also tend to think, that current cups.socket + cups.service design is rather bad and counterproductive .. plain cups.service runs as expected without socket .. let me just summarize again (they are mantioned in 857372 too) current state: 1) when cups.socket is up and something tries to access it it will start anyway cups.service under hood no matter if it is disabled or not 2) we're completely missing documentation for this and also yast printing module is cups.socket-unaware 3) fact, that cups.socket starts cups.service even when cups.service is disabled is very confusing and might produce potential security risk 4) also routing traffic for cupsd via "init" (as it is recognised by netstat -tulnp) seems to be troublesome for cupsd itself .. check related reports. Moreover i'd not also like "init" record in netstat|lsof -i output If it is up to me i'd disable systemd sockets at all .. it's up to (power)users/admins to enable them and use them if they wish regards, daniel ps. we were discussing with bruno friedmann on irc a little bit more current issue and i dare to quote him here: "I've found that we're loosing somewhat standard functionnality since 12.1, even if I'm a big fan and supporter of systemd stuff"
Why is this a systemd issue? This is a issue *how* systemd and its socket forwarding is used. This belongs to configuratipon and/or installation IMHO
This is no issue of the systemd software. This is an issue about systemd unit files. Such issues are related to systemd. See coment#2 what I think what it actually is.
if it works like in theory below it make sense .. [theory below] there is running socket for foo (foo.sock), when something accesses this socket underlying foo service (foo.service) is launched .. foo.socket is able to monitor if it is idle or not and has an option where some timeout is set for shutting down underlying foo.service when idle .. when something accesses foo.socket for first time, foo.service is ran under hood persistently. [example with real values] you have scheduled bacula backup at every midnight .. only bacula on your system requires mysql, which is launched via bacula-dir accessing $mysql.sock .. when backup is done, underlying mysql.service is stopped by systemd after some time of inactivity set within mysql.socket unit option ^^ does it make a sense ? i think that hell yeah ..
(In reply to comment #5) Why you have changed Component and Subject of this bug?
.. when something accesses foo.socket for first time, foo.service is ran under hood persistently. ^^^^^ well, i badly wrote it, there should be mentioned in [theory below] that this is current state
@werner, sorry, perhaps i did it unintentionally when i was adding few others to CC
Daniel Pecka, when you add a comment and bugzilla shows a "mid air collision" but you just submit yours then what you actually submit is your comment plus a set of bugzilla values like Component and Subject (I assume you submit the whole set of bugzilla values) and thereby you overwrite any changes of that values that have happened before.
I think this issue here is meanwhile obsolete since https://bugzilla.novell.com/show_bug.cgi?id=857372#c61 and subsequent comments. *** This bug has been marked as a duplicate of bug 857372 ***