Re: [systemd-devel] [PATCH v2] udev hwdb: Support shipping pre-compiled database in system images
Hello Ivan, Ivan Shapovalov [2014-10-19 5:42 +0400]: > > but this isn't possible AFAIK. The alternative would be to change the > > Exec= to call "hdwb --update --vendor" iff /etc/udev/hwdb.d/ is empty. > > I'm just an innocent bystander, but isn't it possible with these two > lines? > > ConditionPathExists=|!@udevlibexecdir@/hwdb.bin > ConditionDirectoryNotEmpty=|/etc/udev/hwdb.d/ > > This will succeed if EITHER @udevlibexecdir@/hwdb.bin does not exist > OR /etc/udev/hwdb.d/ is not empty. Correct. That's indeed what got pointed out to me on IRC on Friday, and I sent another followup to the list. For some unknown reason that didn't actually hit the list though, so I bounced my reply again this morning. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
Hello all,
in Debian/Ubuntu we don't use the merged /usr tree for now. systemd
generally supports that (HAVE_SPLIT_USR), but doesn't consider that
for ProtectSystem=.
Ansgar (CC'ed) wrote a Debian specific patch for that some months ago.
I generalized it for upstream now.
Thanks for considering,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
>From 84133fed054b02702955d9371a553c213a45ee9e Mon Sep 17 00:00:00 2001
From: Martin Pitt
Date: Sun, 19 Oct 2014 11:56:45 -0400
Subject: [PATCH] Apply ProtectSystem to non-merged /usr directories
For systems that don't use a merged /usr, also protect /bin, /sbin, /lib, and
/lib64.
Separately handle /etc (for ProtectSystem=full) to make the code a bit easier
to read.
Replace hard-coded length of systemd dirs list with strv_length() to avoid
pitfalls.
---
src/core/namespace.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/core/namespace.c b/src/core/namespace.c
index ab03aeb..ac48f4d 100644
--- a/src/core/namespace.c
+++ b/src/core/namespace.c
@@ -420,6 +420,12 @@ static int make_read_only(BindMount *m) {
return r;
}
+#ifdef HAVE_SPLIT_USR
+#define SYSTEM_DIRS STRV_MAKE("/usr", "/bin", "/sbin", "/lib", "-/lib64", "-/boot")
+#else
+#define SYSTEM_DIRS STRV_MAKE("/usr", "-/boot")
+#endif
+
int setup_namespace(
char** read_write_dirs,
char** read_only_dirs,
@@ -448,7 +454,7 @@ int setup_namespace(
strv_length(inaccessible_dirs) +
private_dev +
(protect_home != PROTECT_HOME_NO ? 3 : 0) +
-(protect_system != PROTECT_SYSTEM_NO ? 2 : 0) +
+(protect_system != PROTECT_SYSTEM_NO ? strv_length(SYSTEM_DIRS) : 0) +
(protect_system == PROTECT_SYSTEM_FULL ? 1 : 0);
if (n > 0) {
@@ -496,9 +502,14 @@ int setup_namespace(
}
if (protect_system != PROTECT_SYSTEM_NO) {
-r = append_mounts(&m, protect_system == PROTECT_SYSTEM_FULL ? STRV_MAKE("/usr", "-/boot", "/etc") : STRV_MAKE("/usr", "-/boot"), READONLY);
+r = append_mounts(&m, SYSTEM_DIRS, READONLY);
if (r < 0)
return r;
+if (protect_system == PROTECT_SYSTEM_FULL) {
+r = append_mounts(&m, STRV_MAKE("/etc"), READONLY);
+if (r < 0)
+return r;
+}
}
assert(mounts + n == m);
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Sun, Oct 19, 2014 at 4:58 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Oct 19, 2014 at 12:43:59PM +0200, Colin Guthrie wrote: >> David Herrmann wrote on 19/10/14 12:05: >> > Hi >> > >> > On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie >> > wrote: >> >> Hi, >> >> >> >> How soon after login can I rely on systemd --user having reached >> >> sockets.target? >> >> >> >> This feels a bit like a "you shouldn't rely on that point in time..." >> >> type answer is warrented, and when e.g. GNOME or KDE sessions fully use >> >> systemd to bring themselves up it won't be an issue, but right now, >> >> systemd --user is started by (I think) PAM. >> >> >> >> I want to rely on systemd --user to handle PulseAudio's activation >> >> (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE >> >> might start up their own session stuff and spawn some PA consuming >> >> process before systemd --user has reached it's sockets.target and is >> >> thus ready and listening on PA's native socket. >> >> >> >> Doesn't seem to be a problem on my machine here (it's working really >> >> nicely actually!) but figured I should ask here too. >> > >> > Ordering of user units is (see /usr/lib/systemd/user/): >> > default.target after basic.target after sockets.target >> > >> > PAM creates sessions by calling into systemd's pam-module, which then >> > uses CreateSession() (internal api!). This call does not return until >> > the job of user@.service is done. `systemd --user` notifies READY=1 >> > only after "default.target" is ready. > Hm, this seems a bit excessive, because default.target can take > a while. basic.target would seem more natural. Same -- I never noticed this since I have linger enabled, but I would be a bit worried about the login blocking until /all/ of my services have started... Which makes socket activation not very useful. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Sun, Oct 19, 2014 at 12:43:59PM +0200, Colin Guthrie wrote: > David Herrmann wrote on 19/10/14 12:05: > > Hi > > > > On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie wrote: > >> Hi, > >> > >> How soon after login can I rely on systemd --user having reached > >> sockets.target? > >> > >> This feels a bit like a "you shouldn't rely on that point in time..." > >> type answer is warrented, and when e.g. GNOME or KDE sessions fully use > >> systemd to bring themselves up it won't be an issue, but right now, > >> systemd --user is started by (I think) PAM. > >> > >> I want to rely on systemd --user to handle PulseAudio's activation > >> (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE > >> might start up their own session stuff and spawn some PA consuming > >> process before systemd --user has reached it's sockets.target and is > >> thus ready and listening on PA's native socket. > >> > >> Doesn't seem to be a problem on my machine here (it's working really > >> nicely actually!) but figured I should ask here too. > > > > Ordering of user units is (see /usr/lib/systemd/user/): > > default.target after basic.target after sockets.target > > > > PAM creates sessions by calling into systemd's pam-module, which then > > uses CreateSession() (internal api!). This call does not return until > > the job of user@.service is done. `systemd --user` notifies READY=1 > > only after "default.target" is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
David Herrmann wrote on 19/10/14 12:05: > Hi > > On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie wrote: >> Hi, >> >> How soon after login can I rely on systemd --user having reached >> sockets.target? >> >> This feels a bit like a "you shouldn't rely on that point in time..." >> type answer is warrented, and when e.g. GNOME or KDE sessions fully use >> systemd to bring themselves up it won't be an issue, but right now, >> systemd --user is started by (I think) PAM. >> >> I want to rely on systemd --user to handle PulseAudio's activation >> (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE >> might start up their own session stuff and spawn some PA consuming >> process before systemd --user has reached it's sockets.target and is >> thus ready and listening on PA's native socket. >> >> Doesn't seem to be a problem on my machine here (it's working really >> nicely actually!) but figured I should ask here too. > > Ordering of user units is (see /usr/lib/systemd/user/): > default.target after basic.target after sockets.target > > PAM creates sessions by calling into systemd's pam-module, which then > uses CreateSession() (internal api!). This call does not return until > the job of user@.service is done. `systemd --user` notifies READY=1 > only after "default.target" is ready. > > Long story short: The PAM module blocks until the user-manager is > ready. Therefore, sockets.target is loaded and ready. > > (I'm no expert in sd job handling, so maybe Lennart can confirm this) Thanks for the clarification. This is pretty much what Lennart thought when I quizzed him a couple nights ago, but said he'd double check. It sound like this is indeed the case. Nice :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] udev hwdb: Support shipping pre-compiled database in system images
On Sunday 19 October 2014 at 05:42:28, Ivan Shapovalov wrote: > On Friday 17 October 2014 at 15:44:51, Martin Pitt wrote: > > Hello again, > > > > the previous patch had a typo in the manpage (it said "/lib/udev" > > instead of "/usr/lib/udev" at one place), and also forgot to adjust > > systemd-udev-hwdb-update.service.in. Both done now. > > > > However, the latter currently has a gotcha: > > > > +ConditionPathExists=!@udevlibexecdir@/hwdb.bin > > > > This works correctly if you use this with the "factory reset" > > semantics, i. e. start with an empty /etc. But it would not work if > > you update /usr and have an already existing /etc/udev/hwdb.d/*. So > > ideally the condition would be > > > > ConditionPathExists=!@udevlibexecdir@/hwdb.bin OR > > ConditionDirectoryNotEmpty=/etc/udev/hwdb.d/ > > > > > but this isn't possible AFAIK. The alternative would be to change the > > Exec= to call "hdwb --update --vendor" iff /etc/udev/hwdb.d/ is empty. > > I'm just an innocent bystander, but isn't it possible with these two > lines? > > ConditionPathExists=|!@udevlibexecdir@/hwdb.bin > ConditionDirectoryNotEmpty=|/etc/udev/hwdb.d/ > > This will succeed if EITHER @udevlibexecdir@/hwdb.bin does not exist > OR /etc/udev/hwdb.d/ is not empty. > > Or have I misunderstood you? Ugh, I haven't seen your second message. There's something strange with mail delivery -- I could swear that I've fetched everything before replying... Sorry for the noise. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Hi On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie wrote: > Hi, > > How soon after login can I rely on systemd --user having reached > sockets.target? > > This feels a bit like a "you shouldn't rely on that point in time..." > type answer is warrented, and when e.g. GNOME or KDE sessions fully use > systemd to bring themselves up it won't be an issue, but right now, > systemd --user is started by (I think) PAM. > > I want to rely on systemd --user to handle PulseAudio's activation > (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE > might start up their own session stuff and spawn some PA consuming > process before systemd --user has reached it's sockets.target and is > thus ready and listening on PA's native socket. > > Doesn't seem to be a problem on my machine here (it's working really > nicely actually!) but figured I should ask here too. Ordering of user units is (see /usr/lib/systemd/user/): default.target after basic.target after sockets.target PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after "default.target" is ready. Long story short: The PAM module blocks until the user-manager is ready. Therefore, sockets.target is loaded and ready. (I'm no expert in sd job handling, so maybe Lennart can confirm this) Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
