Re: [systemd-devel] [PATCH] random-seed: break ordering cycle with encrypted tmp partitions
Am Freitag, den 06.01.2012, 16:40 +0100 schrieb Frederic Crozat: Le vendredi 23 décembre 2011 à 01:47 +0100, Tom Gundersen a écrit : Rather than ordering systemd-random-seed-load.service after local-fs.target, start it by path-activation. We need write access to the seed, so we order the path unit after remount-rootfs.service (in case /var is on the root fs). A better solution might be to introduce PathIsWritable=, but that is not necessary in order to solve the problem, and I don't know of any other usecases for it. I've just tested your patch and it works fine ; I quickly tested with / being read-only and mounted writable by systemd and not initrd (which is the default for openSUSE) and it worked fine too. Of course, it would be best to have also confirmation from Michal ;) btw. I get this message with the patch applied: [ 10.607877] systemd-random-seed[102]: Failed to write new random seed file: Bad file descriptor besides that, it seems to work correctly. kind regards thomas 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] [PATCH] random-seed: break ordering cycle with encrypted tmp partitions
Le vendredi 23 décembre 2011 à 01:47 +0100, Tom Gundersen a écrit : Rather than ordering systemd-random-seed-load.service after local-fs.target, start it by path-activation. We need write access to the seed, so we order the path unit after remount-rootfs.service (in case /var is on the root fs). A better solution might be to introduce PathIsWritable=, but that is not necessary in order to solve the problem, and I don't know of any other usecases for it. I've just tested your patch and it works fine ; I quickly tested with / being read-only and mounted writable by systemd and not initrd (which is the default for openSUSE) and it worked fine too. Of course, it would be best to have also confirmation from Michal ;) -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] random-seed: break ordering cycle with encrypted tmp partitions
Zitat von Frederic Crozat fcro...@suse.com: Le vendredi 23 décembre 2011 à 01:47 +0100, Tom Gundersen a écrit : Rather than ordering systemd-random-seed-load.service after local-fs.target, start it by path-activation. We need write access to the seed, so we order the path unit after remount-rootfs.service (in case /var is on the root fs). A better solution might be to introduce PathIsWritable=, but that is not necessary in order to solve the problem, and I don't know of any other usecases for it. I've just tested your patch and it works fine ; I quickly tested with / being read-only and mounted writable by systemd and not initrd (which is the default for openSUSE) and it worked fine too. I wonder what will happen with this patch if /var/lib/random-seed is missing at startup! timeout? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] random-seed: break ordering cycle with encrypted tmp partitions
Le vendredi 06 janvier 2012 à 17:17 +0100, Thomas Meyer a écrit : Zitat von Frederic Crozat fcro...@suse.com: Le vendredi 23 décembre 2011 à 01:47 +0100, Tom Gundersen a écrit : Rather than ordering systemd-random-seed-load.service after local-fs.target, start it by path-activation. We need write access to the seed, so we order the path unit after remount-rootfs.service (in case /var is on the root fs). A better solution might be to introduce PathIsWritable=, but that is not necessary in order to solve the problem, and I don't know of any other usecases for it. I've just tested your patch and it works fine ; I quickly tested with / being read-only and mounted writable by systemd and not initrd (which is the default for openSUSE) and it worked fine too. I wonder what will happen with this patch if /var/lib/random-seed is missing at startup! timeout? Good question. I'd say it will wait forever for it to appear. Maybe we should ensure this file is create in systemd installation ? -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] random-seed: break ordering cycle with encrypted tmp partitions
Rather than ordering systemd-random-seed-load.service after local-fs.target, start it by path-activation. We need write access to the seed, so we order the path unit after remount-rootfs.service (in case /var is on the root fs). A better solution might be to introduce PathIsWritable=, but that is not necessary in order to solve the problem, and I don't know of any other usecases for it. Cc: Frederic Crozat fcro...@suse.com Cc: Michal Schmidt mschm...@redhat.com --- This is my second attempt at solving this problem. The first one had some issues as pointed out by Frederic and Michael. Makefile.am |7 +-- TODO |2 -- units/.gitignore |1 + units/systemd-random-seed-load.path.in| 18 ++ units/systemd-random-seed-load.service.in |3 +-- 5 files changed, 25 insertions(+), 6 deletions(-) create mode 100644 units/systemd-random-seed-load.path.in diff --git a/Makefile.am b/Makefile.am index 170465a..5e236f0 100644 --- a/Makefile.am +++ b/Makefile.am @@ -414,6 +414,7 @@ nodist_systemunit_DATA = \ units/systemd-update-utmp-shutdown.service \ units/systemd-random-seed-save.service \ units/systemd-random-seed-load.service \ + units/systemd-random-seed-load.path \ units/systemd-readahead-collect.service \ units/systemd-readahead-replay.service \ units/systemd-readahead-done.service \ @@ -477,6 +478,7 @@ EXTRA_DIST = \ units/systemd-update-utmp-shutdown.service.in \ units/systemd-random-seed-save.service.in \ units/systemd-random-seed-load.service.in \ + units/systemd-random-seed-load.path.in \ units/systemd-readahead-collect.service.in \ units/systemd-readahead-replay.service.in \ units/systemd-readahead-done.service.in \ @@ -1611,6 +1613,7 @@ SED_PROCESS = \ -e 's,@exec_prefix\@,$(exec_prefix),g' \ -e 's,@libdir\@,$(libdir),g' \ -e 's,@includedir\@,$(includedir),g' \ + -e 's,@localstatedir\@,$(localstatedir),g' \ $ $@ || rm $@ units/%: units/%.in Makefile @@ -1887,7 +1890,7 @@ endif sys-fs-fuse-connections.mount \ systemd-vconsole-setup.service \ systemd-modules-load.service \ - systemd-random-seed-load.service \ + systemd-random-seed-load.path \ systemd-tmpfiles-setup.service \ systemd-sysctl.service \ systemd-ask-password-console.path \ @@ -1901,7 +1904,7 @@ endif $(LN_S) ../sys-fs-fuse-connections.mount sys-fs-fuse-connections.mount \ $(LN_S) ../systemd-vconsole-setup.service systemd-vconsole-setup.service \ $(LN_S) ../systemd-modules-load.service systemd-modules-load.service \ - $(LN_S) ../systemd-random-seed-load.service systemd-random-seed-load.service \ + $(LN_S) ../systemd-random-seed-load.path systemd-random-seed-load.path \ $(LN_S) ../systemd-tmpfiles-setup.service systemd-tmpfiles-setup.service \ $(LN_S) ../systemd-sysctl.service systemd-sysctl.service \ $(LN_S) ../systemd-ask-password-console.path systemd-ask-password-console.path \ diff --git a/TODO b/TODO index a8ab352..ab26eaa 100644 --- a/TODO +++ b/TODO @@ -23,8 +23,6 @@ Features: * Make libselinux, libattr, libcap, libdl dependencies only of the tools which actually need them. -* as Tom Gundersen pointed out there's a always a dep loop if people use crypto file systems with random keys - * unset container= in PID1? * automatically escape unit names passed on the service (i.e. think systemctl start serial-getty.service@serial/by-path/jshdfjsdfhkjh being automatically escaped as necessary. diff --git a/units/.gitignore b/units/.gitignore index cc92c73..202cc62 100644 --- a/units/.gitignore +++ b/units/.gitignore @@ -31,6 +31,7 @@ systemd-vconsole-setup.service systemd-auto-serial-getty.service systemd-shutdownd.service systemd-random-seed-load.service +systemd-random-seed-load.path systemd-random-seed-save.service systemd-initctl.service systemd-stdout-syslog-bridge.service diff --git a/units/systemd-random-seed-load.path.in b/units/systemd-random-seed-load.path.in new file mode 100644 index 000..614c1d4 --- /dev/null +++ b/units/systemd-random-seed-load.path.in @@ -0,0 +1,18 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. + +[Unit] +Description=Random Seed +DefaultDependencies=no +Conflicts=shutdown.target +Before=basic.target
Re: [systemd-devel] [PATCH] random-seed: break ordering cycle with encrypted tmp partitions
On 11/15/2011 09:20 AM, Tom Gundersen wrote: -After=systemd-readahead-collect.service systemd-readahead-replay.service local-fs.target +After=systemd-readahead-collect.service systemd-readahead-replay.service rootfs-remount.service @localstatedir@.mount What if /var/lib itself is a separate mount too? Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] random-seed: break ordering cycle with encrypted tmp partitions
The cycle is caused by our ordering is to coarse. We order random-seed-load after all filesystems, but all we really care about is /var/lib being mounted rw. Waiting for all filesystems means that we would also have to wait for /tmp, which might depend on random-seed-load. Maybe the best way to solve this would have been to allow .path units to not only wait for a path, but also wait for it to have a specific permission. However, since we cannot do that at the moment, this should do the trick for now: We would like to wait for var.mount if /var is on a separate partition, and we'd like to wait for remount-rootfs.service otherwise. I couldn't figure out how to do this conditionally, so we unconditionally wait for both. --- Makefile.am |1 + TODO |2 -- units/systemd-random-seed-load.service.in |4 ++-- 3 files changed, 3 insertions(+), 4 deletions(-) diff --git a/Makefile.am b/Makefile.am index d30d626..ec172b8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1594,6 +1594,7 @@ SED_PROCESS = \ -e 's,@exec_prefix\@,$(exec_prefix),g' \ -e 's,@libdir\@,$(libdir),g' \ -e 's,@includedir\@,$(includedir),g' \ + -e 's,@localstatedir\@,$(localstatedir),g' \ $ $@ || rm $@ units/%: units/%.in Makefile diff --git a/TODO b/TODO index 5303497..a17d409 100644 --- a/TODO +++ b/TODO @@ -21,8 +21,6 @@ Features: * when an instanced service exits, remove its parent cgroup too if possible. -* as Tom Gundersen pointed out there's a always a dep loop if people use crypto file systems with random keys - * unset container= in PID1? * automatically escape unit names passed on the service (i.e. think systemctl start serial-getty.service@serial/by-path/jshdfjsdfhkjh being automatically escaped as necessary. diff --git a/units/systemd-random-seed-load.service.in b/units/systemd-random-seed-load.service.in index a2b6a55..1218040 100644 --- a/units/systemd-random-seed-load.service.in +++ b/units/systemd-random-seed-load.service.in @@ -8,10 +8,10 @@ [Unit] Description=Load Random Seed DefaultDependencies=no -Wants=local-fs.target Conflicts=shutdown.target -After=systemd-readahead-collect.service systemd-readahead-replay.service local-fs.target +After=systemd-readahead-collect.service systemd-readahead-replay.service rootfs-remount.service @localstatedir@.mount Before=sysinit.target shutdown.target +ConditionPathExists=@localstatedir@/lib/random-seed [Service] Type=oneshot -- 1.7.7.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] random-seed: break ordering cycle with encrypted tmp partitions
Le mardi 15 novembre 2011 à 19:20 +1100, Tom Gundersen a écrit : The cycle is caused by our ordering is to coarse. We order random-seed-load after all filesystems, but all we really care about is /var/lib being mounted rw. Waiting for all filesystems means that we would also have to wait for /tmp, which might depend on random-seed-load. Maybe the best way to solve this would have been to allow .path units to not only wait for a path, but also wait for it to have a specific permission. However, since we cannot do that at the moment, this should do the trick for now: We would like to wait for var.mount if /var is on a separate partition, and we'd like to wait for remount-rootfs.service otherwise. I couldn't figure out how to do this conditionally, so we unconditionally wait for both. I did a different fix for openSUSE 12.1 (a bit dirty) where cryptsetup creates a systemd-random-seed-load.service unit in /run (or in /etc I'm not 100% sure), depending if tmp is encrypted or not. Patch is included in another patch to fix lvm on top of cryptsetup (see https://build.opensuse.org/package/view_file?file=storage-after-cryptsetup.patchpackage=systemdproject=home%3Afcrozat%3Asystemdrev=f050db3b3513798555eaca39d76e4a16 and yes, it is ugly ;) I think your option of adding var.mount will cause systemd to complain when /var is not a separate partition.. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
