Bug#727708: Quick upstart and systemd feature comparison
Russ Allbery writes (Bug#727708: Quick upstart and systemd feature comparison): * StandardError=syslog. This would be *so nice* for *so many things*. Particularly for running Java applications, which are very bad about not sending everything to syslog even when one tries to write them to do so. I would start using this immediately. There are various external programs that can do this, but with sysvinit you have to set up the pipelines yourself and worry about the programs dying, whereas systemd takes care of all of that. From the documentation, upstart's default is to log your program's stderr to a file in /var/log/upstart/. I agree that diverting this to syslog would be a useful feature. * Lots of really interesting defense-in-depth security features. I particularly liked ReadWriteDirectories, ReadOnlyDirectories, InaccessibleDirectories, PrivateNetwork, and NoNewPrivileges, which provide a sort of lightweight process containment that would be much easier to use than a full-blown chroot, and in some ways more powerful. I think that this functionality should be provided by auxiliary verb wrapper commands, not welded into init. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21170.54476.586910.862...@chiark.greenend.org.uk
Bug#727708: upstart proposed policy in Debian
On Thu, Dec 19, 2013 at 11:15:24AM +, Ian Jackson wrote: Steve Langasek writes (Bug#727708: upstart proposed policy in Debian): It's also been suggested that instead of requiring modification of the init scripts at all, this logic should be provided by the upstart package in a /lib/lsb/init-functions.d/ fragment that automatically DTRT. If I want to source the lsb init functions, do I have to declare a new dependency on the lsb package, or are they always available ? It requires a dependency on lsb-base. (In practice most init scripts in Debian have been depending on this for some time for pretty logging anyway, so for them it's just a version bump.) -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131219113800.gg5...@riva.ucam.org
Bug#727708: Quick upstart and systemd feature comparison
Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes (Bug#727708: Quick upstart and systemd feature comparison): * Lots of really interesting defense-in-depth security features. I particularly liked ReadWriteDirectories, ReadOnlyDirectories, InaccessibleDirectories, PrivateNetwork, and NoNewPrivileges, which provide a sort of lightweight process containment that would be much easier to use than a full-blown chroot, and in some ways more powerful. I think that this functionality should be provided by auxiliary verb wrapper commands, not welded into init. That has a number of problems: * Init can no longer switch to non-root as most of these features need higher privileges to setup. One would lose the User= and Group= settings. * We would be back at writing shell scripts for configuration: no-new-privileges private-network read-only-directory /etc -- some-daemon * One would have to change all options at once as there is just one command line to change. There is no way to say just disable (enable) x as one has with overriding specific entries from a .service file. * The order of invocations of the wrapper commands might matter and break things if done wrong. Not having to worry about this as init takes care of it removes one source of errors. So I think having these features integrated into init rather than wrapper commands is preferable. Ansgar -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9fxgie1@marvin.43-1.org
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Thu, Dec 19, 2013 at 09:43:05AM +0200, Adrian Bunk wrote: On Wed, Dec 18, 2013 at 02:53:39PM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: [1] Personally, I am sceptical whether it is a good idea to switch to a different init system for jessie. But I am not on a desperate rant against systemd, and if something I bring up can be addressed that is positive for me. Just to give fair warning: right now, based on what I know today, there is basically zero chance that I personally will vote retaining sysvinit for jessie above further discussion. So if you want to convince at least this one member of the technical committee that this is a viable option, you have quite a bit of work to do. Where would further discussion in 1-2 years rank for you? What I suggested earlier in this discussion was not that you vote for keeping sysvinit forever, but: * jessie will continue to use sysvinit, and the TC will re-evaluate the situation after the release of jessie This is equivalent to let others outside of Debian decide our course for us. The Linux ecosystem won't stand still waiting for Debian to make a decision; if Debian doesn't take a decision this cycle, Upstart will remain a single-distro solution in the eyes of many, which means systemd will retain its upstream soapbox and continue to gather contributors. Russ rightly points out that there is a momentum gap between systemd and upstart. It is not insurmountable, if Debian decides to endorse upstart today. But two years further on, it will be. If Debian wants to replace sysvinit with something modern, and wants a say in what that replacement will be, it should decide now. And if Debian's not going to adopt upstart, then we should adopt systemd immediately so that we have a say in its direction between now and jessie, instead of waiting until after jessie and finding ourselves with two more years of entrenched bugs / design problems to sort out when integrating with it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131219172453.gb24...@virgil.dodds.net
Bug#727708: systemd jessie - jessie+1 upgrade problems
Adrian Bunk b...@stusta.de writes: Ubuntu is also using udev and logind without using systemd, so they are and will continue to be available stand-alone. Ubuntu is maintaining a variety of moderately fragile glue in order to make this happen and currently can't upgrade to the current version of logind. This strategy clearly causes some problems for Ubuntu and would cause some similar problems for us. I think everyone agrees that it's *possible*, but my point is that it's increased work that we otherwise wouldn't have to incur. And having them standalone and not as part of the big systemd bundle makes it much easier to ship an older version of udev and/or logind in a release if that avoids upgrade headaches. This proven false by the way that Debian already handles gcc, many library transitions, and multiple other packages where we build different components from different versions for backwards-compatibility reasons. This is not difficult to handle at the packaging layer if we need to do it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bo0cd8xu@windlord.stanford.edu
Bug#727708: Quick upstart and systemd feature comparison
Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes: * Lots of really interesting defense-in-depth security features. I particularly liked ReadWriteDirectories, ReadOnlyDirectories, InaccessibleDirectories, PrivateNetwork, and NoNewPrivileges, which provide a sort of lightweight process containment that would be much easier to use than a full-blown chroot, and in some ways more powerful. I think that this functionality should be provided by auxiliary verb wrapper commands, not welded into init. Why? It feels like it adds (mild) complexity without a whole lot of benefit. The init system (for both systemd and upstart) are already handling setuid, setgid, nice, OOM adjustment, system resource limits, etc. This stuff feels like the same type of thing. Also, note that systemd also has broad support for SELinux and related MAC mechanisms (and upstart has support for apparmor), which use the same type of mechanism. I believe there are some policy challenges in allowing a separate process to handle that setup without compromising security. The init system is already running in the correct trusted context to do that sort of setup. (I'm very interested in the SELinux parts as well, but probably won't be able to use them immediately, so I didn't analyze them in much depth.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gb0d8pv@windlord.stanford.edu
Bug#727708: Quick upstart and systemd feature comparison
On Thu, Dec 19, 2013 at 09:57:48AM -0800, Russ Allbery wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes: * Lots of really interesting defense-in-depth security features. I particularly liked ReadWriteDirectories, ReadOnlyDirectories, InaccessibleDirectories, PrivateNetwork, and NoNewPrivileges, which provide a sort of lightweight process containment that would be much easier to use than a full-blown chroot, and in some ways more powerful. I think that this functionality should be provided by auxiliary verb wrapper commands, not welded into init. Why? It feels like it adds (mild) complexity without a whole lot of benefit. The init system (for both systemd and upstart) are already handling setuid, setgid, nice, OOM adjustment, system resource limits, etc. This stuff feels like the same type of thing. Also, note that systemd also has broad support for SELinux and related MAC mechanisms (and upstart has support for apparmor), which use the same type of mechanism. I believe there are some policy challenges in allowing a separate process to handle that setup without compromising security. The init system is already running in the correct trusted context to do that sort of setup. (I'm very interested in the SELinux parts as well, but probably won't be able to use them immediately, so I didn't analyze them in much depth.) Right, I also agree this kind of thing is best implemented directly in the init system. I don't think it's the highest priority for implementing, but it would have its uses and the init system is best placed to handle it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: Quick upstart and systemd feature comparison
On Thu, Dec 19, 2013 at 09:57:48AM -0800, Russ Allbery wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes: * Lots of really interesting defense-in-depth security features. I particularly liked ReadWriteDirectories, ReadOnlyDirectories, InaccessibleDirectories, PrivateNetwork, and NoNewPrivileges, which provide a sort of lightweight process containment that would be much easier to use than a full-blown chroot, and in some ways more powerful. I think that this functionality should be provided by auxiliary verb wrapper commands, not welded into init. Why? It feels like it adds (mild) complexity without a whole lot of benefit. The init system (for both systemd and upstart) are already handling setuid, setgid, nice, OOM adjustment, system resource limits, etc. This stuff feels like the same type of thing. We should have *at least* auxverb-style commands for this, because they're often useful outside the context of the init system (for example, a private network is useful for building packages; you can do this kind of thing with unshare -n or with the LXC tools). It's a fairly narrow judgement call whether this kind of thing should be directly supported in the init daemon or not; I can certainly see some being useful, although if they're already supported by auxverbs then they would presumably be pretty trivial to add to anything that already has direct support for things like nice. In the case of Upstart's setuid and setgid verbs, I think part of the reasoning was that we had scripts that were doing it by hand in a boilerplate fashion but of course it was important that they get it just right, and it made sense to consolidate the code. That seems to me to be a reasonable metric for whether this belongs in the init daemon. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131219190912.ga5...@riva.ucam.org
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Thu, Dec 19, 2013 at 09:53:01AM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: Ubuntu is also using udev and logind without using systemd, so they are and will continue to be available stand-alone. Ubuntu is maintaining a variety of moderately fragile glue in order to make this happen and currently can't upgrade to the current version of logind. The reasons for not upgrading to the current version of logind aren't to do with any fragility of the existing glue code (the systemd-shim package), but because logind 205 has a new dependency on systemd as cgroup manager, which is architecturally incompatible with other consumers of cgroups in the ecosystem. This needs to be resolved before logind v205 can reasonably be adopted, because it's broken by design and needs to be worked around. This strategy clearly causes some problems for Ubuntu and would cause some similar problems for us. I think everyone agrees that it's *possible*, but my point is that it's increased work that we otherwise wouldn't have to incur. I wouldn't call this a problem, so much as the cost of integrating an OS. systemd-shim weighs in at 2kloc of C code, and is relatively stable. An out-of-pid-1 cgroup manager will bring more code to the table, but only that which is necessary to support systemd-incompatible uses of cgroups. systemd-shim will need extended to bridge between cgmanager and logind. Yes, there's code here that wouldn't need to be written if we all just adopted systemd. But the hidden assumption there is that systemd adequately addresses all the use cases we care about. When you want to support something that upstream doesn't want to support, you get to write code. It seems to me that most of this code would have to be written to support logind on non-Linux anyway, and is a much better choice than supporting consolekit indefinitely for those ports. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: systemd jessie - jessie+1 upgrade problems
Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit : The reasons for not upgrading to the current version of logind aren't to do with any fragility of the existing glue code (the systemd-shim package), but because logind 205 has a new dependency on systemd as cgroup manager, which is architecturally incompatible with other consumers of cgroups in the ecosystem. This needs to be resolved before logind v205 can reasonably be adopted, because it's broken by design and needs to be worked around. The new logind is not “broken by design”. Using the cgroups tree is the most correct and secure way to identify which processes are permitted to access specific devices or services. You might disagree with the idea of a single cgroups manager or prefer a less secure mechanism in order to handle corner cases (that have yet to be described), but that doesn’t make the design less correct. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1387491979.21380.15.camel@tomoe
