Bug#728486: Current patch for resolving lvm/systemd compatibility
Hi Don, Don Armstrong d...@debian.org writes: Do you have an updated patch with this change and a documentation of the tmpfiles.d change? I will draft a resolution shortly to implement this patch, and will open it for discussion. Bastian has uploaded lvm2 2.02.104-1 which contains my patch: http://packages.qa.debian.org/l/lvm2/news/20140129T214940Z.html I tested that new version of lvm2 on my test VM and it addresses the issue we have been seeing before. Therefore, I think there is no need to update my patch :). -- Best regards, Michael -- 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/x6ppn94wqq@midna.zekjur.net
Bug#728486: Current patch for resolving lvm/systemd compatibility
Hi Don, Don Armstrong d...@debian.org writes: Michael: can you go ahead and prepare the patch to fix #728486 which does not use generators so that once the CTTE has resolved the init system question we have a patch in front of us that we can rule on? Of course! Attached you can find a patch against the current lvm2 version in Debian which adds two static service files that contain exactly the same content as what the generator produces¹. The patch also enables installation of the tmpfiles.d(5) configuration file and makes sure that the service files are enabled according to best practices². I tested this on the same test virtual machine that I used all along, and it has the same effect as enabling the generator, i.e. it fixes the problem. For convenience, I also attached lvm2.debdiff which shows the differences in what files are installed, the package’s dependencies, and how the control files are modified. Best viewed with: colordiff --difftype=debdiff /tmp/lvm2.debdiff Please let me know if the patch should be changed in any way to better accomodate the CTTE in ruling on it. ① I removed the SourcePath= directory which is only reasonable in generated units. Furthermore I added an [Install] section with WantedBy=local-fs.target, which is normally done outside of the unit by the generator. ② See https://wiki.debian.org/Systemd/Packaging -- Best regards, Michael From 4eecd2d3168ceb30fc5cc4a9049dfe50e462a8f1 Mon Sep 17 00:00:00 2001 From: Michael Stapelberg stapelb...@debian.org Date: Sat, 18 Jan 2014 11:07:03 +0100 Subject: [PATCH] systemd support --- debian/changelog |7 +++ debian/control |2 +- debian/lvm2-activation-early.service | 22 ++ debian/lvm2-activation.service | 21 + debian/lvm2.install |3 +++ debian/rules |3 +++ 6 files changed, 57 insertions(+), 1 deletion(-) create mode 100644 debian/lvm2-activation-early.service create mode 100644 debian/lvm2-activation.service diff --git a/debian/changelog b/debian/changelog index 25245bb..c94b8c9 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +lvm2 (2.02.98-6systemd1) unstable; urgency=low + + * Add static systemd service files to fix lvm activation edge cases +(closes: #728486) + + -- Michael Stapelberg stapelb...@debian.org Sat, 18 Jan 2014 11:02:32 +0100 + lvm2 (2.02.98-6) unstable; urgency=low * Update init script: diff --git a/debian/control b/debian/control index a280da0..c4e9a7a 100644 --- a/debian/control +++ b/debian/control @@ -3,7 +3,7 @@ Section: admin Priority: optional Maintainer: Debian LVM Team pkg-lvm-maintain...@lists.alioth.debian.org Uploaders: Bastian Blank wa...@debian.org -Build-Depends: dpkg-dev (= 1.16.1~), debhelper (= 8.1.3~), automake, libcman-dev ( 2), libcorosync-dev, libdlm-dev ( 2), libreadline-gplv2-dev, libselinux1-dev, libudev-dev, openais-dev, pkg-config +Build-Depends: dpkg-dev (= 1.16.1~), debhelper (= 8.1.3~), automake, libcman-dev ( 2), libcorosync-dev, libdlm-dev ( 2), libreadline-gplv2-dev, libselinux1-dev, libudev-dev, openais-dev, pkg-config, dh-systemd Standards-Version: 3.9.1 Homepage: http://sources.redhat.com/lvm2/ Vcs-Svn: svn://svn.debian.org/pkg-lvm/lvm2/trunk/ diff --git a/debian/lvm2-activation-early.service b/debian/lvm2-activation-early.service new file mode 100644 index 000..21ba959 --- /dev/null +++ b/debian/lvm2-activation-early.service @@ -0,0 +1,22 @@ +# Automatically generated by lvm2-activation-generator. +# +# This unit is responsible for direct activation of LVM2 logical volumes +# if lvmetad daemon is not used (global/use_lvmetad=0 lvm.conf setting), +# hence volume autoactivation is not applicable. +# Direct LVM2 activation requires udev to be settled! + +[Unit] +Description=Activation of LVM2 logical volumes +Documentation=man:lvm(8) man:vgchange(8) +DefaultDependencies=no +After=systemd-udev-settle.service +Before=cryptsetup.target +Before=local-fs.target shutdown.target +Wants=systemd-udev-settle.service + +[Service] +ExecStart=/sbin/lvm vgchange -aay --sysinit +Type=oneshot + +[Install] +WantedBy=local-fs.target diff --git a/debian/lvm2-activation.service b/debian/lvm2-activation.service new file mode 100644 index 000..9b273fd --- /dev/null +++ b/debian/lvm2-activation.service @@ -0,0 +1,21 @@ +# Automatically generated by lvm2-activation-generator. +# +# This unit is responsible for direct activation of LVM2 logical volumes +# if lvmetad daemon is not used (global/use_lvmetad=0 lvm.conf setting), +# hence volume autoactivation is not applicable. +# Direct LVM2 activation requires udev to be settled! + +[Unit] +Description=Activation of LVM2 logical volumes +Documentation=man:lvm(8) man:vgchange(8) +DefaultDependencies=no +After=lvm2-activation-early.service cryptsetup.target +Before=local-fs.target shutdown.target +Wants=systemd-udev-settle.service + +[Service
Bug#727708: loose ends for init system decision
Hi Ian, Ian Jackson ijack...@chiark.greenend.org.uk writes: This is particularly the case for build-dependencies on an avowedly and intentionally non-portable program. Of course this can be made conditional, but this is IMO too fiddly. Adding [linux-any] to the Build-Depends line is not too fiddly, and if the goal is to enable optional upstream support for systemd, that will be sufficient. Besides, in general, it's up to the packager to decide what is or is not too fiddly in how they want to package software. Adding [linux-any] to the Build-Depends is not sufficient. It is also necessary to make the actual source code conditionally use sd_notify, using #ifdefs or other similar techniques. The conditional compilation will have to be automated (perhaps with autoconf if the package has it - an then we need new --with[out]-systemd configuration options to avoid miscompilation; or perhaps in an ad hoc way if the daemon doesn't use autoconf). The fact that the systemd-specific command line option may or may not be compiled in needs to be mentioned in the documentation, along with text which allows the user to know whether it's included in the version they actually have. This turns what could be a simple change into a multi-part epic involving all of the components of the package: primary source code, upstream build system and portability layer, Debian build system, documentation, and so on. No, this is all not true :). libsystemd-daemon already contains the conditionals necessary to be a noop on non-linux: http://sources.debian.net/src/systemd/204-5/src/libsystemd-daemon/sd-daemon.c Therefore, you can just use it, and don’t need to use any conditionals on your end, neither in the compilation process, nor in the code itself. That being said, I just checked and realized the package is not available on non-linux. I’ll look into that now, since intuitively there is no reason for this. -- Best regards, Michael -- 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/x6r48srh2v@midna.zekjur.net
Bug#727708: systemd socket activation protocol rationale
Hi Ian, [still sending this after Uoti’s reply, because my version has some more detail] Ian Jackson ijack...@chiark.greenend.org.uk writes: Why do only some of the environment variables start SD_ ? We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START. SD_LISTEN_FDS_START is a #define from sd-daemon.h, not an environment variable. What is the rationale behind the use of the LISTEN_PID variable and the pid check ? It seems to me that at the very least this might make “In addition we set $LISTEN_PID to the PID of the daemon that shall receive the fds, because environment variables are normally inherited by sub-processes and hence could confuse processes further down the chain” ¹ it hard to wrap up a socket-activated daemon in a shell script. I am not entirely sure what use cases you have in mind, but typically a wrapper script at some point just execs the daemon itself, right? In that case, it’s not a problem. I think it would be good, regardless of what the TC decides on the init system question for Debian, for systemd and upstart to converge on a single reasonable protocol. Helmut Grohne has done some work in that direction², speaking to the relevant people at DebConf 13 in person. I am not entirely sure about the current status of these efforts, maybe Helmut can comment…? ① http://0pointer.de/blog/projects/systemd.html, feature 8 ② https://lists.debian.org/debian-devel/2013/06/msg7.html -- Best regards, Michael -- 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/x61u1fcadl@midna.zekjur.net
Bug#727708: Aribtrarily breaking working interfaces?
Hi Steve, Steve McIntyre st...@einval.com writes: I've been following #725714 with interest in the last few days. It seems that the arbitrary breakage of the module/firmware loading interface in udev last year [1] is now causing major issues for us and our users in debian-installer. I take offense with the fact that you write “arbitrary breakage”. It implies that Kay et al. (udev upstream) _arbitrarily_ decided (as opposed to “with good reason, after careful consideration”) to break that interface. I do not have the impression that this is the case. And I certainly do not see any evidence supporting that. So please, can we assume good faith when talking about other human beings that are involved in our community? -- Best regards, Michael -- 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/x6wqj9ciyc@midna.zekjur.net
Bug#728486: Current patch for resolving lvm/systemd compatibility
Hi Don, Don Armstrong d...@debian.org writes: I'd like to get this particular bug discussion restarted. Thanks for your mail. From my understanding, a static, non generator version of lvm2_activation_generator_systemd_red_hat.c will allow for the activation of lvm2 after the addition of an lvm device by udev/systemd. Michael: Is this correct? To the best of my knowledge, a static non-generator patch will make lvm2 work with systemd, yes. I offer to work on producing an easily mergable patch, should Bastian agree to that. -- Best regards, Michael -- 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/x67gbmamy1@midna.lan
Bug#727708: systemd (security) bugs (was: init system question) [and 1 more messages]
Hi Ian, Ian Jackson ijack...@chiark.greenend.org.uk writes: My point was that someone who is writing an init system for concurrent startup and dynamic service management needs to have a good understanding of concurrent system design, and in particular of race hazards. I wouldn't expect a person or people who had such an understanding to make many mistakes of the kind seen here. Neither do I, but there is no evidence for _many_ of these problems. Personally, I don’t know about every little detail in fd passing either. If I read you correctly, you seem to be saying one needs to be an expert in a given area before being allowed to write code in it. I think it works the other way around: by writing code in that area, you become an expert in it. What a startling statement. This is not some desktop toy we are talking about; this is critical core system infrastructure. I would prefer my pid 1 to have been written by experts. It appears that you are saying that systemd wasn't and that this isn't important! To clarify: I do think (most?) systemd authors are experts. I am also saying that experts can make mistakes, and that having the expectation that software has 0 bugs is unreasonable. I also stand by my statement that one cannot be an expert in a subject area before having experience in that subject area. Sure, one can prepare, but there is the proverb “practice makes perfect”. Instead of focusing on the actual security issues, what I’d much rather look at is the process with which such bugs are fixed. I.e. are security problems acknowledged as such, are they fixed clearly and in a timely manner? Are there enough eyes looking at the project to uncover, report and collaborate in fixing the issues? I don't think having a functioning security response process is a substitute for good system design, and a high initial code quality. No argument there. I think having all three of them is better, and that’s my opinion of systemd, at least of pid 1, which I have looked at more closely than at the other parts of the larger system. Also, and I think that should go without saying, if this branch of the discussion is considered as reasoning against systemd in the decision process, I’d like to see similar data on the other init systems :). You are of course welcome to go and find that information. I may be misunderstanding how this works, but I strongly believe that if the ctte looks at the security track record of systemd, it MUST also look at the security track record of the other contenders. I.e., I consider it unfair to say “we’re not using systemd because it had security bugs, we’ll chose X instead, but we didn’t look at its security at all”. That said, I’d love to help, but I don’t have the time to look at the security track record of other init systems in detail. Sorry. -- Best regards, Michael -- 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/x6iova9mt0@midna.lan
Bug#727708: systemd (security) bugs (was: init system question)
Hi Ian, Ian Jackson ijack...@chiark.greenend.org.uk writes: CVE summary Debian BTS Redhat 2012-0871systemd-logind insecure file creation ? 795853 2012-1101DoS from systemctl status 662029 799902 2012-1174TOCTOU deletion race in systemd-logind 664364 803358 2013-4327insecure use of polkit 723713 1006680 2013-4391systemd journald integer overflow 725357 859051 2013-4392TOCTOU race updating file perms 725357 859060 2013-4393systemd journald DoS725357 859104 2013-4394improper sanitization of XKB layouts725357 862324 It isn't always 100% clear to me from reading these which of them apply to systemd's init replacement. But reading the systemd debate 2012-1101 does, I think 2013-4327 and 2013-4392 might, all the others do not affect the init part of src:systemd. Furthermore, I think it is fair to look at bugs in non-pid-1 parts of the systemd codebase when assessing the likely code quality of the pid 1 parts. I don’t really agree. The code quality of other parts of the systemd ecosystem sure are related and probably provide a good trend of the overall code quality. However, there are some “subsystems” of systemd, which are to a big part written by non-core contributors. Take for example networkd, a minimal network configuration for static (server-ish) setups, which was largely implemented by Tom Gundersen: http://cgit.freedesktop.org/systemd/systemd/log/src/network Or take journald, which also has plenty of contributors: http://cgit.freedesktop.org/systemd/systemd/log/src/journal?ofs=50 http://cgit.freedesktop.org/systemd/systemd/log/src/journal?ofs=100 One can compare this to the Linux kernel, I think: looking at any subsystem will give you a somewhat useful idea about the overall code quality, but it’s not fair to say linux’s syscall security sucks just by looking at the filesystem code. I should say that it is hard to write code with no security bugs at all. But I think our benchmark for security bugs in our init system ought to be very few, particularly if we are making a specific implementation effectively mandatory. And I don't think I would like to accept justifications (for a large bug count) along the lines of but systemd does so much more; I think the security bugs that come with a large codebase, or having more functionality exposed to ordinary users, are a direct and very relevant downside to such a large codebase or large attack surface. They sure are. OTOH, chosing the init system that receives the most attention in form of development and is adopted by many other distributions helps us a lot with security issues. They are no longer just our problem, but other distributions also care about getting them fixed quickly. There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392) which I think a concurrent init system author ought really to be competent to avoid. (And the system should be designed, so far as possible, to reduce the opportunity for such races.) “a concurrent init system author” sounds strange on multiple counts: systemd was not written by one author. It is also not concurrent (in fact it is single-threaded and only links to pthreads to call sync asynchronously on shutdown), but event-based. As for competency, I am sure that everybody involved has learned their lesson and will avoid such issues in the future. I am also sure that other init systems have (had) similar bugs. And if there is no evidence of that yet, maybe nobody looked really closely yet…? :) The systemctl status resource usage DoS (CVE-2012-1101) is an understandable resource leak, given systemd's design. But for me it raises this question: why is the system designed in such a way that the critical pid 1 is required to implement functionality (and unprivileged-facing interfaces) in which such a resource leak is (a) a likely programming error and then (b) exposed so as to be exploitable. a) I think “a likely programming error” is an exaggeration. Do you have data on how often there were resource leaks in systemd? b) I am unclear on how exactly this was exploitable, and the bugs lack explanation unfortunately. Furthermore, I think Lennart’s explanation of why arbitrary units must be able to be created is fair: https://bugzilla.redhat.com/show_bug.cgi?id=680122#c1 AIUI the journald integer overflow (CVE-2013-4391) is a remotely exploitable bug, if you have configured journald to allow remote logging. (I assume this isn't the default configuration but haven't checked.) journald does not provide remote logging. See https://lists.fedoraproject.org/pipermail/devel/2013-July/185585.html The other journald one (CVE-2013-4393) seems to stem from a poor design decision: journald expects to be given an fd and then reads from it. The authors
Bug#727708: FYI: upstream’s take
Hi, my apologies for not replying to any messages within the thread, but I think my mail is orthogonal to the other messages. Lennart Poettering wrote about the systemd upstream point of view on the discussion we are currently having: https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf I’d like to specifically stress this part: And yeah, we, upstream, are of course open to answer any questions you might have. So, please feel encouraged to explicitly ask upstream about any points that you feel are important and/or unclear. Also, it shouldn’t need saying, but let’s be sure: the same goes for pkg-systemd-maintainers within Debian. If you have any questions, please talk to us. You can reach us via pkg-systemd-maintain...@lists.alioth.debian.org, and feel free to CC me specifically. -- Best regards, Michael -- 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/x6hac1xn0h@midna.lan
