Re: [systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev
Lennart Poettering wrote: > And noexec doesn't really make much sense for these dirs, as this > blocks mmap() with MAP_EXEC and there are plenty apps that want to use > that. Moreover "noexec" is at best a protection against accidental > execution and not a security mechanism since it is trivially easy to > circumvent (just call the interpreter directly with the file to > execute as first arg, which for ELF means "/lib64/ld-linux-x86-64.so.2 > $BINARY") That workaround doesn't actually work anymore; the former (blocking mmap with MAP_EXEC) exists specifically to protect against the latter (running the interpreter directly). $ mount | grep '/run ' tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1620848k,mode=755) $ sudo cp -a /bin/ls /run/ls $ /run/ls bash: /run/ls: Permission denied (126) $ /lib64/ld-linux-x86-64.so.2 /run/ls /run/ls: error while loading shared libraries: /run/ls: failed to map segment from shared object (127) $ It's theoretically possible to work around *that* if you have permission to run arbitrary code and to remap memory from write to execute (both of which might also be locked down). But even without that, mount -o noexec does meaningfully improve security, and the trivial workaround no longer works. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Robust getpid caching via MADV_WIPEONFORK?
[Bcced to other potentially interested folks.] As discussed in various places, glibc removed the getpid() cache in 2.25, since it was not robust against all possible ways to fork a process. Linux 4.14 added MADV_WIPEONFORK, which robustly ensures that a page gets wiped to zero on any possible process fork. The commit message adding it even mentions, as a use case: > - systemd/pulseaudio API checks (fail after fork) (replacing a getpid >check, which is too slow without a PID cache) Given that, I wanted to start a thread about the idea of making getpid() caching, and for that matter other potential uses of pthread_atfork(), robust using MADV_WIPEONFORK when available. I don't necessarily want to advocate this; rather, since it seems likely that other applications may wish to do things like this, I wanted to collect some information and discuss whether it makes sense or not. I wrote a simple test program, attached (warning: quick hack), that benchmarks the stock getpid() versus a trivial cached version of getpid() using MADV_WIPEONFORK (marked as "noinline" to simulate providing it as a library function), just to get a rough idea. This produced the following numbers on my system: mmap: 3292.00 ns madvise: 3273.00 ns uncached getpid: 1 calls in 4569540458.000 ns; 45.695 ns/call cached getpid: 1 calls in 132862952.000 ns; 1.329 ns/call That's a significant speedup per call, but that savings only pays off if the program calls getpid() more than ~150 times, or ~75 times if the separate mmap can be avoided. Given that, I don't think it makes sense for glibc to take this approach in the standard getpid(). For any program that doesn't call getpid() extensively, this seems like a pessimization, and many such programs can do such caching themselves without worrying about an unexpected fork(). I think only specialized library code would ever want to do this. Hopefully these numbers will help anyone looking to implement such caching in their own code. - Josh Triplett #include #include #include #include #include #include #include #ifndef MADV_WIPEONFORK #define MADV_WIPEONFORK 18 #endif static pid_t *cached_getpid_page; __attribute__((noinline)) static pid_t cached_getpid(void) { pid_t pid = *cached_getpid_page; if (!pid) *cached_getpid_page = pid = getpid(); return pid; } static struct timespec get_time(void) { struct timespec t; if (clock_gettime(CLOCK_MONOTONIC_RAW, ) < 0) err(1, "clock_gettime"); return t; } static double to_nsec(struct timespec t) { return t.tv_sec * 10 + t.tv_nsec; if (clock_gettime(CLOCK_MONOTONIC_RAW, ) < 0) err(1, "clock_gettime"); printf("%llu.%09lu\n", (unsigned long long)t.tv_sec, t.tv_nsec); } static const int ITERATIONS = 1; int main(void) { struct timespec start, end; double duration; start = get_time(); void *page = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (page == MAP_FAILED) err(1, "mmap"); end = get_time(); duration = to_nsec(end) - to_nsec(start); printf("mmap: %f ns\n", duration); start = get_time(); if (madvise(page, 4096, MADV_WIPEONFORK) < 0) err(1, "madvise"); cached_getpid_page = page; end = get_time(); duration = to_nsec(end) - to_nsec(start); printf("madvise: %f ns\n", duration); start = get_time(); for (int i = 0; i < ITERATIONS; i++) getpid(); end = get_time(); duration = to_nsec(end) - to_nsec(start); printf("uncached getpid: %d calls in %14.3f ns; %7.3f ns/call\n", ITERATIONS, duration, duration/ITERATIONS); start = get_time(); for (int i = 0; i < ITERATIONS; i++) cached_getpid(); end = get_time(); duration = to_nsec(end) - to_nsec(start); printf(" cached getpid: %d calls in %14.3f ns; %7.3f ns/call\n", ITERATIONS, duration, duration/ITERATIONS); return 0; } ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ~/.local/bin , XDG, and environment variable overrides
On Tue, Aug 29, 2017 at 06:43:58PM +0200, Lennart Poettering wrote: > On Sa, 26.08.17 10:43, Josh Triplett (j...@joshtriplett.org) wrote: > > > systemd's file-hierarchy manpage > > <https://www.freedesktop.org/software/systemd/man/file-hierarchy.html> > > documents ~/.local/bin as the place under $HOME to install executables > > in $PATH, and quite a bit of software has adopted that. However, unlike > > the directories specified in the XDG Base Directory specification, this > > doesn't include an environment variable (like $XDG_DATA_HOME for > > ~/.local/share) to override it. I've seen a proposal to use > > $XDG_BIN_HOME for that. Might it make sense to include that, and start > > getting software to adopt it? > > Quite frankly, I am not sure that having env vars for all those dirs > was a good idea in the first place, but sure, if you want to > standardize that, please go ahead, you have my support. A patch to the > XDG basedir spec should be very welcome. Developers on some platforms (e.g. Haiku) wanted the ability to set those paths. This came up in the context of installing Rust binaries, which didn't want to hardcode ~/.local/bin , and using something like $XDG_DATA_HOME/../bin seems quite wrong as well. > But do not the architecture issues with such a dir, i.e. home > directories might be shared between systems of different archs, and > binary programs compiled for one arch and placed in these dirs are > unlikely to work on the other. I figure this is the reason why this > concept was never included in XDG basedir spec, but then again I think > it's fine to still add it as long as the issue is highlighted. The second version of the patch from Johannes Löthberg seems to address that. I also suspect that $XDG_BIN_HOME might actually help folks who want to deal with that issue, by setting it to a multiarch-style directory that includes the architecture triple. (Though that would also imply installing architecture-independent scripts multiple times; however, I don't think it's worth trying to define an elaborate scheme to handle that, not when things like /usr/local/bin and /usr/bin *don't*. We're not trying to solve that new and rare problem here; we're trying to document the defacto standard that already exists.) > > Also, would it make sense to add ~/.local/bin to the XDG Base Directory > > specification itself? I'd be happy to write up an addition to the spec > > for that, and propose it on the appropriate list. > > If you add the env var then it should be added to the xdg basedir spec. See the patches from Johannes Löthberg on the XDG list. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] ~/.local/bin , XDG, and environment variable overrides
systemd's file-hierarchy manpage <https://www.freedesktop.org/software/systemd/man/file-hierarchy.html> documents ~/.local/bin as the place under $HOME to install executables in $PATH, and quite a bit of software has adopted that. However, unlike the directories specified in the XDG Base Directory specification, this doesn't include an environment variable (like $XDG_DATA_HOME for ~/.local/share) to override it. I've seen a proposal to use $XDG_BIN_HOME for that. Might it make sense to include that, and start getting software to adopt it? Also, would it make sense to add ~/.local/bin to the XDG Base Directory specification itself? I'd be happy to write up an addition to the spec for that, and propose it on the appropriate list. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Monitor path to commit to git
Lennart Poettering wrote: > inotify doesn't really provide such a feature, and fanotify is > crap. Leaving aside any other issues with fanotify, it doesn't seem to provide this feature either; "man fanotify" says "Fanotify monitoring of directories is not recursive: to monitor subdirectories under a directory, additional marks must be created." That aside, though, can you elaborate on other issues with fanotify? (Or, do you have or know of something already written on that topic that you could point to?) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY
On April 20, 2015 8:39:33 AM PDT, Lennart Poettering lenn...@poettering.net wrote: On Fri, 17.04.15 08:52, Josh Triplett (j...@joshtriplett.org) wrote: On Thu, Apr 16, 2015 at 08:23:45PM +0200, Lennart Poettering wrote: Now, to put together a more complex scenario for you: consider a small web UI that can be used to set the system time. It should realy run at minimal privileges, after all it has a surface to the web. Hence you write it as daemon, make it run as a user id of its own, set up a chroot() or a file system namespace, but you do keep CAP_SYS_TIME and a bus connection open. With that setup the web daemon can pretty much only set the system clock, and if it exploited cannot be used for much else. It will not have access to /dev/rtc, due to the file system namespace, but it can nicely set the system clock via timedated still, and pretty much only that, and the clock will be synced to the RTC by it. To map this back to your earlier request for an example. In this case process A is the web UI daemon. Capability B is CAP_SYS_TIME. Message C is the SetTime() bus call. Daemon D is timedated. If the web UI daemon would not have CAP_SYS_TIME it couldn't change the time like this -- unless of course that web UI daemon would run as UID 0 all the time, which is certainly much much less desirable, given that it is a network facing daemon. I agree with your statement that any process with the ability to do an operation directly (bypassing systemd) should have the ability to do so safely through systemd. However, that doesn't provide a complete solution, because the reverse shouldn't necessarily be true: it should be possible to grant a process the ability to do an operation safely through systemd *without* granting it permission to do so directly. yeah, for that side we have polkit. Now, I can still see the value in saying if you have permission to do the unsafe thing directly, you can do the safe thing. However, that seems like an optional enhancement, rather than core required functionality to make sane use of (k)dbus. kdbus without the capability-passing mechanism still seems like a wildly useful enhancement. Well, sure, I mean, the caps stuff are *not* essential to kdbus' mode of operation. But I do believe they make the system better, and should be used preferably over broad uid == 0 checks. I'd certainly agree that uid 0 checks are a bad idea, since as little code should run as root as possible. However, rather than handing out capabilities that allow bypassing systemd and talking directly to the kernel, it seems preferable to run unprivileged and grant the necessary permissions to that process. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY
On Thu, Apr 16, 2015 at 08:23:45PM +0200, Lennart Poettering wrote: Now, to put together a more complex scenario for you: consider a small web UI that can be used to set the system time. It should realy run at minimal privileges, after all it has a surface to the web. Hence you write it as daemon, make it run as a user id of its own, set up a chroot() or a file system namespace, but you do keep CAP_SYS_TIME and a bus connection open. With that setup the web daemon can pretty much only set the system clock, and if it exploited cannot be used for much else. It will not have access to /dev/rtc, due to the file system namespace, but it can nicely set the system clock via timedated still, and pretty much only that, and the clock will be synced to the RTC by it. To map this back to your earlier request for an example. In this case process A is the web UI daemon. Capability B is CAP_SYS_TIME. Message C is the SetTime() bus call. Daemon D is timedated. If the web UI daemon would not have CAP_SYS_TIME it couldn't change the time like this -- unless of course that web UI daemon would run as UID 0 all the time, which is certainly much much less desirable, given that it is a network facing daemon. I agree with your statement that any process with the ability to do an operation directly (bypassing systemd) should have the ability to do so safely through systemd. However, that doesn't provide a complete solution, because the reverse shouldn't necessarily be true: it should be possible to grant a process the ability to do an operation safely through systemd *without* granting it permission to do so directly. For instance, a user's desktop session should have permission to shut down the system politely by asking systemd to shut down, without having permission to shut down the system impolitely by invoking the reboot system call. Or in your time service example, the admin may want to grant the web service permission to set the clock via timedated, but *not* directly via settimeofday. (I'm assuming below that you agree there should be a mechanism to offer privileges to do a safe operation but *not* the corresponding unsafe operation. If you don't agree, let's talk about that first.) Given that, some mechanism needs to exist to grant the safe-but-not-unsafe permissions. That might be polkit, or something like dbus bus policies, or some other mechanism. Now, I can still see the value in saying if you have permission to do the unsafe thing directly, you can do the safe thing. However, that seems like an optional enhancement, rather than core required functionality to make sane use of (k)dbus. kdbus without the capability-passing mechanism still seems like a wildly useful enhancement. Based on that, I'm wondering if there's any fundamental reason not to split that out as a separate patch, get the remaining less-controversial parts of kdbus merged, and then make the case for that separately. Then kdbus would be available for everyone to use sooner, and later on it could gain some additional features. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup: Do not warn If the key is /dev/*random
On Mon, Feb 02, 2015 at 04:42:21PM +0100, Lennart Poettering wrote: On Mon, 02.02.15 12:06, Cristian Rodríguez (crrodriguez at opensuse.org) wrote: Using /dev/urandom as a key is valid for swap, do not warn if this devices are world readable. --- src/cryptsetup/cryptsetup.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c index e6b37ac..38930ae 100644 --- a/src/cryptsetup/cryptsetup.c +++ b/src/cryptsetup/cryptsetup.c @@ -624,8 +624,10 @@ int main(int argc, char *argv[]) { /* Ideally we'd do this on the open fd, but since this is just a * warning it's OK to do this in two steps. */ -if (stat(key_file, st) = 0 (st.st_mode 0005)) -log_warning(Key file %s is world-readable. This is not a good idea!, key_file); +if (stat(key_file, st) = 0 (st.st_mode 0005)) { +if(!STR_IN_SET(key_file, /dev/urandom, /dev/random, /dev/hw_random)) +log_warning(Key file %s is world-readable. This is not a good idea!, key_file); +} I'd prefer if we'd change the check instead to only apply to S_ISREG() files. This way we wouldn't have to list all RNG device nodes. With the exception of /dev/*random, you don't want a world-readable device used for a key either. Some people have setups that use a USB device (e.g. /dev/sd* or /dev/disk/by-*/*) as a keyfile, and in that case, the file should *not* be world-readable. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dynamic uid allocation (was: [PATCH] loopback setup in unprivileged containers)
Lennart Poettering wrote: Hmm, so, I thought a lot about this in the past weeks. I think the way I'd really like to see this work in the end is that we never have to persist the UID mappings. This could work if the kernel would provide us with the ability to bind mount a file system into the container applying a fixed UID shift. That way, the shifted UIDs would never hit the actual disk, and hence we wouldn't have to persist their mappings. It ought to be possible to run an arbitrary distribution inside a container, even a distribution that itself wants to run sandboxed applications in containers. Nesting matters, so a bare shift may not suffice. On the other hand, a shift is the simplest solution for simple utility containers, such as those launched by systemd-nspawn. nspawn could trivially avoid persisting the UID map by applying a shift, while a full container solution might want to construct persistent dynamic UID maps, or integrate with special PAM/NSS modules, or any number of other creative solutions. Container UID handling was exactly what I had in mind when I sent in a kernel patch for the setusers() system call. If an unprivileged user on the host system can have a pile of UIDs handed to them by the host system, and can use any of those IDs in their UID map, then they can set up any arbitrary container UID handling without further assistance from host root. A PAM module on the host could then, by policy, hand some or all unprivileged users a substantial stack of host UIDs that they can arbitrarily map to container UIDs; together with support for applying UID maps to a mounted filesystem, that would provide all the necessary kernel support. In addition to containers, that would also provide a sensible solution for a smarter fakeroot-style tool that lets a user construct filesystems with slightly more complicated policies than root owns everything, again without any help from host root other than here, have a pile of subordinate UIDs. I'd be happy to revisit kernel setusers() support if anyone would be interested in saying yes, this is the solution we want. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/5] Enhancements to libabc template project
On Thu, Dec 25, 2014 at 10:20:14PM +0100, Kay Sievers wrote: On Sat, Dec 6, 2014 at 11:46 PM, Josh Triplett j...@joshtriplett.org wrote: I went to use libabc as the basis for a new library, and found a few issues; rather than just correcting them in my own library, I'd like to push the changes back into libabc. Josh Triplett (5): Makefile.am: Don't add abc subdirectory to include path Makefile.am: Don't define LIBEXECDIR autogen.sh: set -e separately, rather than putting -e in the shebang line m4/.gitignore: Remove stray blank line. Remove FSF mailing address All five patches applied. Thanks! - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] libabc, sub-objects, and reference counting
On Mon, Dec 08, 2014 at 05:09:17PM +0100, David Herrmann wrote: On Sun, Dec 7, 2014 at 2:39 AM, Josh Triplett j...@joshtriplett.org wrote: The sample libabc includes functions to get a thing, as a sample sub-object of the overall library context. Each thing has a reference to the parent library context, and a function to return that reference. Given that, shouldn't abc_thing_new_from_string call abc_ref, and abc_thing_unref call abc_unref? Sure! Sounds like an oversight in libabc. I'll send in a patch. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] libabc: Make things hold a reference to their context
The sample libabc includes functions to get a thing, as a sample sub-object of the overall library context. Each thing has a reference to the parent library context, and a function to return that reference. Given that, abc_thing_new_from_string should call abc_ref, and abc_thing_unref should call abc_unref when freeing a thing. --- src/libabc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/libabc.c b/src/libabc.c index d6ef0b4..21e434b 100644 --- a/src/libabc.c +++ b/src/libabc.c @@ -251,6 +251,7 @@ ABC_EXPORT struct abc_thing *abc_thing_unref(struct abc_thing *thing) if (thing-refcount 0) return NULL; dbg(thing-ctx, context %p released\n, thing); +abc_unref(thing-ctx); free(thing); return NULL; } @@ -269,7 +270,7 @@ ABC_EXPORT int abc_thing_new_from_string(struct abc_ctx *ctx, const char *string return -ENOMEM; t-refcount = 1; -t-ctx = ctx; +t-ctx = abc_ref(ctx); *thing = t; return 0; } -- 2.1.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/5] Enhancements to libabc template project
I went to use libabc as the basis for a new library, and found a few issues; rather than just correcting them in my own library, I'd like to push the changes back into libabc. Josh Triplett (5): Makefile.am: Don't add abc subdirectory to include path Makefile.am: Don't define LIBEXECDIR autogen.sh: set -e separately, rather than putting -e in the shebang line m4/.gitignore: Remove stray blank line. Remove FSF mailing address Makefile.am | 2 -- autogen.sh | 3 ++- m4/.gitignore| 1 - src/abc/libabc.h | 4 src/libabc-private.h | 4 src/libabc.c | 4 src/test-libabc.c| 4 7 files changed, 2 insertions(+), 20 deletions(-) -- 2.1.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/5] Makefile.am: Don't add abc subdirectory to include path
Source files, including those in the library itself, should include abc/example.h, not example.h. --- Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 1ac18d0..aa53b51 100644 --- a/Makefile.am +++ b/Makefile.am @@ -7,7 +7,6 @@ AM_CPPFLAGS = \ -include $(top_builddir)/config.h \ -DSYSCONFDIR=\$(sysconfdir)\ \ -DLIBEXECDIR=\$(libexecdir)\ \ - -I${top_srcdir}/src/abc \ -I${top_srcdir}/src AM_CFLAGS = ${my_CFLAGS} \ -- 2.1.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/5] Makefile.am: Don't define LIBEXECDIR
As README points out, the library should not execute out-of-process tools. Thus, it should never need to know LIBEXECDIR. --- Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index aa53b51..d7dcaed 100644 --- a/Makefile.am +++ b/Makefile.am @@ -6,7 +6,6 @@ AM_MAKEFLAGS = --no-print-directory AM_CPPFLAGS = \ -include $(top_builddir)/config.h \ -DSYSCONFDIR=\$(sysconfdir)\ \ - -DLIBEXECDIR=\$(libexecdir)\ \ -I${top_srcdir}/src AM_CFLAGS = ${my_CFLAGS} \ -- 2.1.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/5] autogen.sh: set -e separately, rather than putting -e in the shebang line
Otherwise, if someone uses sh autogen.sh, the -e will get ignored. --- autogen.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/autogen.sh b/autogen.sh index 0d60b0a..07afd85 100755 --- a/autogen.sh +++ b/autogen.sh @@ -1,4 +1,5 @@ -#!/bin/sh -e +#!/bin/sh +set -e if [ -f .git/hooks/pre-commit.sample -a ! -f .git/hooks/pre-commit ] ; then cp -p .git/hooks/pre-commit.sample .git/hooks/pre-commit \ -- 2.1.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 4/5] m4/.gitignore: Remove stray blank line.
--- m4/.gitignore | 1 - 1 file changed, 1 deletion(-) diff --git a/m4/.gitignore b/m4/.gitignore index 8bab51c..38066dd 100644 --- a/m4/.gitignore +++ b/m4/.gitignore @@ -3,4 +3,3 @@ ltoptions.m4 ltsugar.m4 ltversion.m4 lt~obsolete.m4 - -- 2.1.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 5/5] Remove FSF mailing address
It has changed in the past, and these days, anyone can get a copy of the LGPL via the web rather than by post. --- src/abc/libabc.h | 4 src/libabc-private.h | 4 src/libabc.c | 4 src/test-libabc.c| 4 4 files changed, 16 deletions(-) diff --git a/src/abc/libabc.h b/src/abc/libabc.h index 8924033..d33129b 100644 --- a/src/abc/libabc.h +++ b/src/abc/libabc.h @@ -12,10 +12,6 @@ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. - - You should have received a copy of the GNU Lesser General Public - License along with this library; if not, write to the Free Software - Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ #ifndef _LIBABC_H_ diff --git a/src/libabc-private.h b/src/libabc-private.h index a76f822..7c9ad93 100644 --- a/src/libabc-private.h +++ b/src/libabc-private.h @@ -12,10 +12,6 @@ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. - - You should have received a copy of the GNU Lesser General Public - License along with this library; if not, write to the Free Software - Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ #ifndef _LIBABC_PRIVATE_H_ diff --git a/src/libabc.c b/src/libabc.c index 23fdcd5..d6ef0b4 100644 --- a/src/libabc.c +++ b/src/libabc.c @@ -12,10 +12,6 @@ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. - - You should have received a copy of the GNU Lesser General Public - License along with this library; if not, write to the Free Software - Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ #include stdio.h diff --git a/src/test-libabc.c b/src/test-libabc.c index 6734944..9051966 100644 --- a/src/test-libabc.c +++ b/src/test-libabc.c @@ -12,10 +12,6 @@ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. - -You should have received a copy of the GNU General Public License along -with this program; if not, write to the Free Software Foundation, Inc., -51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. */ #include stdio.h -- 2.1.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] libabc, sub-objects, and reference counting
The sample libabc includes functions to get a thing, as a sample sub-object of the overall library context. Each thing has a reference to the parent library context, and a function to return that reference. Given that, shouldn't abc_thing_new_from_string call abc_ref, and abc_thing_unref call abc_unref? In particular, consider a language binding for a language with garbage collection, built-in reference counting, or some other mechanism to avoid requiring explicit calls to _unref functions. The creation of a new abc context would call abc_new, and arrange to call abc_unref when the program no longer needs that abc context. Similarly, the creation of a new thing would take an abc context, call abc_thing_new_from_string (or some similar creation function), and arrange to call abc_thing_unref when the program no longer needs that thing. Code in such a language might create an abc, immediately create a thing, use the thing, and let all the now-unreferenced objects get destroyed. If use the thing references the thing but not the abc context, the language could decide to call abc_unref immediately after creating the thing, then use the thing, which would have a pointer to an invalid abc context. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 01/10] man/logind.conf.xml: Make man logind.conf.d work too
--- Makefile-man.am | 5 + man/logind.conf.xml | 1 + 2 files changed, 6 insertions(+) diff --git a/Makefile-man.am b/Makefile-man.am index f817a05..906a968 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -1110,8 +1110,13 @@ MANPAGES += \ man/logind.conf.5 \ man/systemd-logind.service.8 MANPAGES_ALIAS += \ + man/logind.conf.d.5 \ man/systemd-logind.8 +man/logind.conf.d.5: man/logind.conf.5 man/systemd-logind.8: man/systemd-logind.service.8 +man/logind.conf.d.html: man/logind.conf.html + $(html-alias) + man/systemd-logind.html: man/systemd-logind.service.html $(html-alias) diff --git a/man/logind.conf.xml b/man/logind.conf.xml index 0b35f51..ca7525f 100644 --- a/man/logind.conf.xml +++ b/man/logind.conf.xml @@ -44,6 +44,7 @@ refnamediv refnamelogind.conf/refname +refnamelogind.conf.d/refname refpurposeLogin manager configuration files/refpurpose /refnamediv -- 2.1.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 02/10] man: Factor out a common snippet for .d directories and precedence
Several manpages contain duplicate text describing a standard set of .d configuration directories, with the usual sorting, precedence, overrides, and so on. Factor this common text out using XInclude before proliferating it even further. --- Makefile-man.am| 1 + man/binfmt.d.xml | 30 -- man/logind.conf.xml| 27 +-- man/modules-load.d.xml | 26 -- man/standard-conf.xml | 45 + man/sysctl.d.xml | 33 - man/sysusers.d.xml | 27 ++- 7 files changed, 69 insertions(+), 120 deletions(-) create mode 100644 man/standard-conf.xml diff --git a/Makefile-man.am b/Makefile-man.am index 906a968..c24606a 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -1638,6 +1638,7 @@ EXTRA_DIST += \ man/sd_uid_get_state.xml \ man/sd_watchdog_enabled.xml \ man/shutdown.xml \ + man/standard-conf.xml \ man/standard-options.xml \ man/sysctl.d.xml \ man/systemctl.xml \ diff --git a/man/binfmt.d.xml b/man/binfmt.d.xml index 2270166..55a3df0 100644 --- a/man/binfmt.d.xml +++ b/man/binfmt.d.xml @@ -19,7 +19,8 @@ You should have received a copy of the GNU Lesser General Public License along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=binfmt.d conditional='ENABLE_BINFMT' +refentry id=binfmt.d conditional='ENABLE_BINFMT' + xmlns:xi=http://www.w3.org/2001/XInclude; refentryinfo titlebinfmt.d/title @@ -74,33 +75,10 @@ paraEmpty lines and lines beginning with ; and # are ignored. Note that this means you may not use ; and # as delimiter in binary format rules./para - -paraEach configuration file shall be named in the -style of filenamereplaceableprogram/replaceable.conf/filename. -Files in filename/etc//filename override files -with the same name in filename/usr/lib//filename -and filename/run//filename. Files in -filename/run//filename override files with the -same name in filename/usr/lib//filename. Packages -should install their configuration files in -filename/usr/lib//filename, files in -filename/etc//filename are reserved for the local -administrator, who may use this logic to override the -configuration files installed from vendor -packages. All files are sorted by their filename in -lexicographic order, regardless of which of the -directories they reside in. If multiple files specify -the same binary type name, the entry in the file with -the lexicographically latest name will be applied./para - -paraIf the administrator wants to disable a -configuration file supplied by the vendor, the -recommended way is to place a symlink to -filename/dev/null/filename in -filename/etc/binfmt.d//filename bearing the -same filename./para /refsect1 +xi:include href=standard-conf.xml xpointer=confd / + refsect1 titleExample/title example diff --git a/man/logind.conf.xml b/man/logind.conf.xml index ca7525f..e927cf4 100644 --- a/man/logind.conf.xml +++ b/man/logind.conf.xml @@ -22,7 +22,8 @@ along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=logind.conf conditional='ENABLE_LOGIND' +refentry id=logind.conf conditional='ENABLE_LOGIND' + xmlns:xi=http://www.w3.org/2001/XInclude; refentryinfo titlelogind.conf/title productnamesystemd/productname @@ -59,29 +60,11 @@ titleDescription/title paraThese files configure various parameters of the systemd login manager, citerefentryrefentrytitlesystemd-logind.service/refentrytitlemanvolnum8/manvolnum/citerefentry./para - -paraEach configuration file shall be named in the style of -filenamereplaceablefilename/replaceable.conf/filename. -Files in filename/etc//filename override files with the -same name in filename/usr/lib//filename and -filename/run//filename. Files in -filename/run//filename override files with the same name in -filename/usr/lib//filename. Packages should install their -configuration files in filename/usr/lib//filename. Files in -filename/etc//filename are reserved for the local -administrator, who may use this logic to override the -configuration files installed by vendor packages. All -
[systemd-devel] [PATCH 03/10] core: Support system.conf.d and user.conf.d directories in the usual search paths
--- Makefile-man.am | 12 +++- man/systemd-system.conf.xml | 25 - man/systemd.xml | 10 ++ src/core/main.c | 9 - src/core/system.conf| 3 +++ src/core/user.conf | 3 +++ 6 files changed, 47 insertions(+), 15 deletions(-) diff --git a/Makefile-man.am b/Makefile-man.am index c24606a..f025be0 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -195,6 +195,7 @@ MANPAGES_ALIAS += \ man/sd_journal_wait.3 \ man/sd_machine_get_ifindices.3 \ man/sd_notifyf.3 \ + man/system.conf.d.5 \ man/systemd-ask-password-console.path.8 \ man/systemd-ask-password-wall.path.8 \ man/systemd-ask-password-wall.service.8 \ @@ -227,7 +228,8 @@ MANPAGES_ALIAS += \ man/systemd-udevd-kernel.socket.8 \ man/systemd-udevd.8 \ man/systemd-update-done.8 \ - man/systemd-user.conf.5 + man/systemd-user.conf.5 \ + man/user.conf.d.5 man/SD_ALERT.3: man/sd-daemon.3 man/SD_CRIT.3: man/sd-daemon.3 man/SD_DEBUG.3: man/sd-daemon.3 @@ -301,6 +303,7 @@ man/sd_journal_test_cursor.3: man/sd_journal_get_cursor.3 man/sd_journal_wait.3: man/sd_journal_get_fd.3 man/sd_machine_get_ifindices.3: man/sd_machine_get_class.3 man/sd_notifyf.3: man/sd_notify.3 +man/system.conf.d.5: man/systemd-system.conf.5 man/systemd-ask-password-console.path.8: man/systemd-ask-password-console.service.8 man/systemd-ask-password-wall.path.8: man/systemd-ask-password-console.service.8 man/systemd-ask-password-wall.service.8: man/systemd-ask-password-console.service.8 @@ -334,6 +337,7 @@ man/systemd-udevd-kernel.socket.8: man/systemd-udevd.service.8 man/systemd-udevd.8: man/systemd-udevd.service.8 man/systemd-update-done.8: man/systemd-update-done.service.8 man/systemd-user.conf.5: man/systemd-system.conf.5 +man/user.conf.d.5: man/systemd-system.conf.5 man/SD_ALERT.html: man/sd-daemon.html $(html-alias) @@ -553,6 +557,9 @@ man/sd_machine_get_ifindices.html: man/sd_machine_get_class.html man/sd_notifyf.html: man/sd_notify.html $(html-alias) +man/system.conf.d.html: man/systemd-system.conf.html + $(html-alias) + man/systemd-ask-password-console.path.html: man/systemd-ask-password-console.service.html $(html-alias) @@ -652,6 +659,9 @@ man/systemd-update-done.html: man/systemd-update-done.service.html man/systemd-user.conf.html: man/systemd-system.conf.html $(html-alias) +man/user.conf.d.html: man/systemd-system.conf.html + $(html-alias) + if ENABLE_BACKLIGHT MANPAGES += \ diff --git a/man/systemd-system.conf.xml b/man/systemd-system.conf.xml index 284516d..dfb180c 100644 --- a/man/systemd-system.conf.xml +++ b/man/systemd-system.conf.xml @@ -22,7 +22,8 @@ along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=systemd-system.conf +refentry id=systemd-system.conf + xmlns:xi=http://www.w3.org/2001/XInclude; refentryinfo titlesystemd-system.conf/title productnamesystemd/productname @@ -44,25 +45,39 @@ refnamediv refnamesystemd-system.conf/refname +refnamesystem.conf.d/refname refnamesystemd-user.conf/refname -refpurposeSystem and session service manager configuration file/refpurpose +refnameuser.conf.d/refname +refpurposeSystem and session service manager configuration files/refpurpose /refnamediv refsynopsisdiv parafilename/etc/systemd/system.conf/filename/para + parafilename/etc/systemd/system.conf.d/*.conf/filename/para + parafilename/run/systemd/system.conf.d/*.conf/filename/para + parafilename/usr/lib/systemd/system.conf.d/*.conf/filename/para parafilename/etc/systemd/user.conf/filename/para + parafilename/etc/systemd/user.conf.d/*.conf/filename/para + parafilename/run/systemd/user.conf.d/*.conf/filename/para + parafilename/usr/lib/systemd/user.conf.d/*.conf/filename/para /refsynopsisdiv refsect1 titleDescription/title -paraWhen run as system instance systemd reads the -configuration file filenamesystem.conf/filename, -otherwise filenameuser.conf/filename. These +paraWhen run as a system instance, systemd interprets the +configuration file filenamesystem.conf/filename and the +files in filenamesystem.conf.d/filename directories; when +run as a user instance, systemd interprets the configuration +file filenameuser.conf/filename and the files in +filenameuser.conf.d/filename directories. These configuration files contain a few settings controlling basic
[systemd-devel] [PATCH 05/10] systemd-sleep: Support sleep.conf.d directories in the usual search paths
--- Makefile-man.am | 5 + man/systemd-sleep.conf.xml | 15 --- man/systemd-suspend.service.xml | 3 ++- src/shared/sleep-config.c | 7 --- 4 files changed, 23 insertions(+), 7 deletions(-) diff --git a/Makefile-man.am b/Makefile-man.am index e0c15fa..2a0d73e 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -196,6 +196,7 @@ MANPAGES_ALIAS += \ man/sd_journal_wait.3 \ man/sd_machine_get_ifindices.3 \ man/sd_notifyf.3 \ + man/sleep.conf.d.5 \ man/system.conf.d.5 \ man/systemd-ask-password-console.path.8 \ man/systemd-ask-password-wall.path.8 \ @@ -305,6 +306,7 @@ man/sd_journal_test_cursor.3: man/sd_journal_get_cursor.3 man/sd_journal_wait.3: man/sd_journal_get_fd.3 man/sd_machine_get_ifindices.3: man/sd_machine_get_class.3 man/sd_notifyf.3: man/sd_notify.3 +man/sleep.conf.d.5: man/systemd-sleep.conf.5 man/system.conf.d.5: man/systemd-system.conf.5 man/systemd-ask-password-console.path.8: man/systemd-ask-password-console.service.8 man/systemd-ask-password-wall.path.8: man/systemd-ask-password-console.service.8 @@ -562,6 +564,9 @@ man/sd_machine_get_ifindices.html: man/sd_machine_get_class.html man/sd_notifyf.html: man/sd_notify.html $(html-alias) +man/sleep.conf.d.html: man/systemd-sleep.conf.html + $(html-alias) + man/system.conf.d.html: man/systemd-system.conf.html $(html-alias) diff --git a/man/systemd-sleep.conf.xml b/man/systemd-sleep.conf.xml index d724960..99e0e33 100644 --- a/man/systemd-sleep.conf.xml +++ b/man/systemd-sleep.conf.xml @@ -22,7 +22,8 @@ You should have received a copy of the GNU Lesser General Public License along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=systemd-sleep.conf +refentry id=systemd-sleep.conf + xmlns:xi=http://www.w3.org/2001/XInclude; refentryinfo titlesystemd-sleep.conf/title productnamesystemd/productname @@ -44,11 +45,15 @@ along with systemd; If not, see http://www.gnu.org/licenses/. refnamediv refnamesystemd-sleep.conf/refname +refnamesleep.conf.d/refname refpurposeSuspend and hibernation configuration file/refpurpose /refnamediv refsynopsisdiv parafilename/etc/systemd/sleep.conf/filename/para +parafilename/etc/systemd/sleep.conf.d/*.conf/filename/para +parafilename/run/systemd/sleep.conf.d/*.conf/filename/para +parafilename/usr/lib/systemd/sleep.conf.d/*.conf/filename/para /refsynopsisdiv refsect1 @@ -98,7 +103,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. /varlistentry /variablelist -paraSettings in this file determine what strings +paraSettings in these files determine what strings will be written to filename/sys/power/disk/filename and filename/sys/power/state/filename by @@ -108,12 +113,16 @@ along with systemd; If not, see http://www.gnu.org/licenses/. attempts to suspend or hibernate the machine./para /refsect1 + xi:include href=standard-conf.xml xpointer=confd / + xi:include href=standard-conf.xml xpointer=conf / + refsect1 titleOptions/title paraThe following options can be configured in the literal[Sleep]/literal section of -filename/etc/systemd/sleep.conf/filename:/para +filename/etc/systemd/sleep.conf/filename or a +filenamesleep.conf.d/filename file:/para variablelist class='systemd-directives' varlistentry diff --git a/man/systemd-suspend.service.xml b/man/systemd-suspend.service.xml index 9a3ae1b..375c255 100644 --- a/man/systemd-suspend.service.xml +++ b/man/systemd-suspend.service.xml @@ -114,7 +114,8 @@ filename/sys/power/state/filename, to trigger the actual system suspend. What exactly is written where can be configured in the literal[Sleep]/literal -section of filename/etc/systemd/sleep.conf/filename. +section of filename/etc/systemd/sleep.conf/filename or a +filenamesleep.conf.d/filename file. See citerefentryrefentrytitlesystemd-sleep.conf/refentrytitlemanvolnum5/manvolnum/citerefentry. /para /refsect1 diff --git a/src/shared/sleep-config.c b/src/shared/sleep-config.c index 0fd307d..ae14c6b 100644 --- a/src/shared/sleep-config.c +++ b/src/shared/sleep-config.c @@ -48,9 +48,10 @@ int parse_sleep_config(const char *verb, char ***_modes, char ***_states) { {} }; -config_parse(NULL, PKGSYSCONFDIR /sleep.conf, NULL, - Sleep\0, - config_item_table_lookup, items, false, false, true, NULL); +config_parse_many(PKGSYSCONFDIR /sleep.conf, + CONF_DIRS_NULSTR(systemd/sleep.conf), + Sleep\0, config_item_table_lookup, items, + false, NULL); if (streq(verb, suspend)) {
[systemd-devel] [PATCH 07/10] coredump: Support coredump.conf.d directories in the usual search paths
--- Makefile-man.am | 6 -- man/coredump.conf.xml | 14 +++--- src/journal/coredump.c| 9 + src/journal/coredump.conf | 3 +++ 4 files changed, 23 insertions(+), 9 deletions(-) diff --git a/Makefile-man.am b/Makefile-man.am index 593dc40..01d3408 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -714,8 +714,10 @@ MANPAGES += \ man/coredumpctl.1 \ man/systemd-coredump.8 MANPAGES_ALIAS += \ - # - + man/coredump.conf.d.5 +man/coredump.conf.d.5: man/coredump.conf.5 +man/coredump.conf.d.html: man/coredump.conf.html + $(html-alias) endif diff --git a/man/coredump.conf.xml b/man/coredump.conf.xml index 5eb5c5f..37916f0 100644 --- a/man/coredump.conf.xml +++ b/man/coredump.conf.xml @@ -22,7 +22,8 @@ along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=coredump.conf conditional=ENABLE_COREDUMP +refentry id=coredump.conf conditional=ENABLE_COREDUMP + xmlns:xi=http://www.w3.org/2001/XInclude; refentryinfo titlecoredump.conf/title productnamesystemd/productname @@ -44,20 +45,27 @@ refnamediv refnamecoredump.conf/refname -refpurposeCoredump storage configuration file/refpurpose +refnamecoredump.conf.d/refname +refpurposeCoredump storage configuration files/refpurpose /refnamediv refsynopsisdiv parafilename/etc/systemd/coredump.conf/filename/para +parafilename/etc/systemd/coredump.conf.d/*.conf/filename/para +parafilename/run/systemd/coredump.conf.d/*.conf/filename/para +parafilename/usr/lib/systemd/coredump.conf.d/*.conf/filename/para /refsynopsisdiv refsect1 titleDescription/title -paraThis file configures the behaviour of commandsystemd-coredump/command, +paraThese files configure the behaviour of commandsystemd-coredump/command, a handler for core dumps invoked by the kernel./para /refsect1 + xi:include href=standard-conf.xml xpointer=confd / + xi:include href=standard-conf.xml xpointer=conf / + refsect1 titleOptions/title diff --git a/src/journal/coredump.c b/src/journal/coredump.c index d889ed1..be45a68 100644 --- a/src/journal/coredump.c +++ b/src/journal/coredump.c @@ -120,10 +120,11 @@ static int parse_config(void) { {} }; -return config_parse(NULL, /etc/systemd/coredump.conf, NULL, -Coredump\0, -config_item_table_lookup, items, -false, false, true, NULL); +return config_parse_many(/etc/systemd/coredump.conf, + CONF_DIRS_NULSTR(systemd/coredump.conf), + Coredump\0, + config_item_table_lookup, items, + false, NULL); } static int fix_acl(int fd, uid_t uid) { diff --git a/src/journal/coredump.conf b/src/journal/coredump.conf index 0cc328f..0fe9fe8 100644 --- a/src/journal/coredump.conf +++ b/src/journal/coredump.conf @@ -5,6 +5,9 @@ # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # +# You can override the directives in this file by creating files in +# /etc/systemd/coredump.conf.d/*.conf. +# # See coredump.conf(5) for details [Coredump] -- 2.1.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 09/10] timesyncd: Support timesyncd.conf.d directories in the usual search paths
--- Makefile-man.am| 7 ++- man/timesyncd.conf.xml | 17 +++-- src/timesync/timesyncd-conf.c | 9 + src/timesync/timesyncd.conf.in | 3 +++ 4 files changed, 25 insertions(+), 11 deletions(-) diff --git a/Makefile-man.am b/Makefile-man.am index 36e0ebb..e3c43b2 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -1244,11 +1244,16 @@ MANPAGES += \ man/systemd-timesyncd.service.8 \ man/timesyncd.conf.5 MANPAGES_ALIAS += \ - man/systemd-timesyncd.8 + man/systemd-timesyncd.8 \ + man/timesyncd.conf.d.5 man/systemd-timesyncd.8: man/systemd-timesyncd.service.8 +man/timesyncd.conf.d.5: man/timesyncd.conf.5 man/systemd-timesyncd.html: man/systemd-timesyncd.service.html $(html-alias) +man/timesyncd.conf.d.html: man/timesyncd.conf.html + $(html-alias) + endif if ENABLE_VCONSOLE diff --git a/man/timesyncd.conf.xml b/man/timesyncd.conf.xml index aeb7182..1a56c2c 100644 --- a/man/timesyncd.conf.xml +++ b/man/timesyncd.conf.xml @@ -22,7 +22,8 @@ along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=timesyncd.conf conditional='ENABLE_TIMESYNCD' +refentry id=timesyncd.conf conditional='ENABLE_TIMESYNCD' + xmlns:xi=http://www.w3.org/2001/XInclude; refentryinfo titletimesyncd.conf/title productnamesystemd/productname @@ -44,24 +45,28 @@ refnamediv refnametimesyncd.conf/refname -refpurposeNetwork Time Synchronization configuration file/refpurpose +refnametimesyncd.conf.d/refname +refpurposeNetwork Time Synchronization configuration files/refpurpose /refnamediv refsynopsisdiv parafilename/etc/systemd/timesyncd.conf/filename/para + parafilename/etc/systemd/timesyncd.conf.d/*.conf/filename/para + parafilename/run/systemd/timesyncd.conf.d/*.conf/filename/para + parafilename/usr/lib/systemd/timesyncd.conf.d/*.conf/filename/para /refsynopsisdiv refsect1 titleDescription/title -paraWhen starting, systemd-timesyncd will read the -configuration file -filenametimesyncd.conf/filename. This -configuration file controls NTP network time +paraThese configuration files control NTP network time synchronization./para /refsect1 +xi:include href=standard-conf.xml xpointer=confd / +xi:include href=standard-conf.xml xpointer=conf / + refsect1 titleOptions/title diff --git a/src/timesync/timesyncd-conf.c b/src/timesync/timesyncd-conf.c index 4c2dcdb..be1f4bb 100644 --- a/src/timesync/timesyncd-conf.c +++ b/src/timesync/timesyncd-conf.c @@ -97,8 +97,9 @@ int config_parse_servers( int manager_parse_config_file(Manager *m) { assert(m); -return config_parse(NULL, /etc/systemd/timesyncd.conf, NULL, -Time\0, -config_item_perf_lookup, timesyncd_gperf_lookup, -false, false, true, m); +return config_parse_many(/etc/systemd/timesyncd.conf, + CONF_DIRS_NULSTR(systemd/timesyncd.conf), + Time\0, + config_item_perf_lookup, timesyncd_gperf_lookup, + false, m); } diff --git a/src/timesync/timesyncd.conf.in b/src/timesync/timesyncd.conf.in index 674a51d..fc3c6c4 100644 --- a/src/timesync/timesyncd.conf.in +++ b/src/timesync/timesyncd.conf.in @@ -5,6 +5,9 @@ # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # +# You can override the directives in this file by creating files in +# /etc/systemd/timesyncd.conf.d/*.conf. +# # See timesyncd.conf(5) for details [Time] -- 2.1.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 08/10] resolved: Support resolved.conf.d directories in the usual search paths
--- Makefile-man.am | 5 + man/resolved.conf.xml| 16 +++- src/resolve/resolved-conf.c | 9 + src/resolve/resolved.conf.in | 3 +++ 4 files changed, 24 insertions(+), 9 deletions(-) diff --git a/Makefile-man.am b/Makefile-man.am index 01d3408..36e0ebb 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -1204,8 +1204,13 @@ MANPAGES += \ man/resolved.conf.5 \ man/systemd-resolved.service.8 MANPAGES_ALIAS += \ + man/resolved.conf.d.5 \ man/systemd-resolved.8 +man/resolved.conf.d.5: man/resolved.conf.5 man/systemd-resolved.8: man/systemd-resolved.service.8 +man/resolved.conf.d.html: man/resolved.conf.html + $(html-alias) + man/systemd-resolved.html: man/systemd-resolved.service.html $(html-alias) diff --git a/man/resolved.conf.xml b/man/resolved.conf.xml index c582368..36013a5 100644 --- a/man/resolved.conf.xml +++ b/man/resolved.conf.xml @@ -22,7 +22,8 @@ along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=resolved.conf conditional='ENABLE_RESOLVED' +refentry id=resolved.conf conditional='ENABLE_RESOLVED' + xmlns:xi=http://www.w3.org/2001/XInclude; refentryinfo titleresolved.conf/title productnamesystemd/productname @@ -44,23 +45,28 @@ refnamediv refnameresolved.conf/refname -refpurposeNetwork Name Resolution configuration file/refpurpose +refnameresolved.conf.d/refname +refpurposeNetwork Name Resolution configuration files/refpurpose /refnamediv refsynopsisdiv parafilename/etc/systemd/resolved.conf/filename/para + parafilename/etc/systemd/resolved.conf.d/*.conf/filename/para + parafilename/run/systemd/resolved.conf.d/*.conf/filename/para + parafilename/usr/lib/systemd/resolved.conf.d/*.conf/filename/para /refsynopsisdiv refsect1 titleDescription/title -paraWhen starting, systemd-resolved will read the -configuration file filenameresolved.conf/filename. -This configuration file controls local DNS and LLMNR +paraThese configuration files control local DNS and LLMNR name resolving./para /refsect1 +xi:include href=standard-conf.xml xpointer=confd / +xi:include href=standard-conf.xml xpointer=conf / + refsect1 titleOptions/title diff --git a/src/resolve/resolved-conf.c b/src/resolve/resolved-conf.c index 63e87f8..81b9d34 100644 --- a/src/resolve/resolved-conf.c +++ b/src/resolve/resolved-conf.c @@ -147,8 +147,9 @@ int config_parse_support( int manager_parse_config_file(Manager *m) { assert(m); -return config_parse(NULL, /etc/systemd/resolved.conf, NULL, -Resolve\0, -config_item_perf_lookup, resolved_gperf_lookup, -false, false, true, m); +return config_parse_many(/etc/systemd/resolved.conf, + CONF_DIRS_NULSTR(systemd/resolved.conf), + Resolve\0, + config_item_perf_lookup, resolved_gperf_lookup, + false, m); } diff --git a/src/resolve/resolved.conf.in b/src/resolve/resolved.conf.in index c8263d6..e5a19ee 100644 --- a/src/resolve/resolved.conf.in +++ b/src/resolve/resolved.conf.in @@ -5,6 +5,9 @@ # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # +# You can override the directives in this file by creating files in +# /etc/systemd/resolved.conf.d/*.conf. +# # See resolved.conf(5) for details [Resolve] -- 2.1.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 10/10] journald-remote: Support journal-remote.conf.d and journal-upload.conf.d directories in the usual search paths
--- src/journal-remote/journal-remote.c | 8 src/journal-remote/journal-upload.c | 8 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/src/journal-remote/journal-remote.c b/src/journal-remote/journal-remote.c index a5d40cb..6ec5ad2 100644 --- a/src/journal-remote/journal-remote.c +++ b/src/journal-remote/journal-remote.c @@ -1131,10 +1131,10 @@ static int parse_config(void) { { Remote, TrustedCertificateFile, config_parse_path, 0, arg_trust }, {}}; -return config_parse(NULL, PKGSYSCONFDIR /journal-remote.conf, NULL, -Remote\0, -config_item_table_lookup, items, -false, false, true, NULL); +return config_parse_many(PKGSYSCONFDIR /journal-remote.conf, + CONF_DIRS_NULSTR(systemd/journal-remote.conf), + Remote\0, config_item_table_lookup, items, + false, NULL); } static void help(void) { diff --git a/src/journal-remote/journal-upload.c b/src/journal-remote/journal-upload.c index 8be0f93..62853b6 100644 --- a/src/journal-remote/journal-upload.c +++ b/src/journal-remote/journal-upload.c @@ -532,10 +532,10 @@ static int parse_config(void) { { Upload, TrustedCertificateFile, config_parse_path, 0, arg_trust }, {}}; -return config_parse(NULL, PKGSYSCONFDIR /journal-upload.conf, NULL, -Upload\0, -config_item_table_lookup, items, -false, false, true, NULL); +return config_parse_many(PKGSYSCONFDIR /journal-upload.conf, + CONF_DIRS_NULSTR(systemd/journal-upload.conf), + Upload\0, config_item_table_lookup, items, + false, NULL); } static void help(void) { -- 2.1.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] NEWS: Document new .conf.d configuration directories
Also provide guidance to distributions, to make sure they don't start dropping files in the configuration directories in /etc/. --- NEWS | 13 + 1 file changed, 13 insertions(+) diff --git a/NEWS b/NEWS index 0d3ab2b..8fc0720 100644 --- a/NEWS +++ b/NEWS @@ -7,6 +7,19 @@ CHANGES WITH 218: will spew out warnings if the compilation fails. This requires libxkbcommon to be installed. +* All systemd programs that read standalone configuration files + in /etc now also support a corresponding series of + .conf.d configuration directories in /etc/, /run/, + /usr/local/lib/, /usr/lib/, and (if configured with + --enable-split-usr) /lib/. In particular, the following + configuration files now have corresponding configuration + directories: system.conf user.conf, logind.conf, + journald.conf, sleep.conf, bootchart.conf, coredump.conf, + resolved.conf, timesyncd.conf, journal-remote.conf, and + journal-upload.conf. Note that distributions should use the + configuration directories in /usr/lib/; the directories in + /etc/ are reserved for the system administrator. + CHANGES WITH 217: * journalctl gained the new options -t/--identifier= to match -- 2.1.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] NEWS: Document new .conf.d configuration directories
On Sun, Nov 30, 2014 at 12:23:07AM +0100, Lennart Poettering wrote: Applied! Thanks! Thanks for the fast response! Out of curiosity, what's the process/criteria to apply for commit access? (I have an fd.o account already.) I didn't see any documented on the systemd homepage. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] logind: Support logind.conf.d directories in the usual search paths
On Thu, Nov 27, 2014 at 01:45:43AM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Nov 26, 2014 at 01:24:53PM +0100, Gergely Nagy wrote: Josh == Josh Triplett j...@joshtriplett.org writes: Josh This makes it possible to drop in logind configuration snippets from a Josh package or other configuration management mechanism. [...] Josh If this approach looks sensible, I'll send further patches for various Josh other tools with configuration files, such as journald and Josh timesyncd; I recently hit an issue where a journald.conf.d/ would have been incredibly useful. Any news on this patchset, by any chance? Applied. Sorry for the delay. Thanks! And no problem. It would be great if you could prepare patches for the other deamons. Will do. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] statelessy system
Zbigniew Jędrzejewski-Szmek wrote: On Mon, Nov 03, 2014 at 12:24:42PM +0100, Lennart Poettering wrote: Would be happy to take a patch that makes those cases check for a config file in /usr/lib as fallback though, to cover all bases. Didn't we have a patch to support .d directories floated on the ml? Can't seem to find it at the moment. Yes, I posted one for logind.conf.d; see message IDs 20141029120251.GA30088@thin ([PATCH 1/2] Introduce CONF_DIRS_NULSTR helper to define standard conf dirs) and 20141029121045.GA5365@thin ([PATCH 2/2] logind: Support logind.conf.d directories in the usual search paths). http://lists.freedesktop.org/archives/systemd-devel/2014-October/024676.html http://lists.freedesktop.org/archives/systemd-devel/2014-October/024677.html I'd love to see those applied. If those work for you, I can produce additional patches for the other config files in /etc/systemd. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] Introduce CONF_DIRS_NULSTR helper to define standard conf dirs
Several different systemd tools define a nulstr containing a standard series of configuration file directories, in /etc, /run, /usr/local/lib, /usr/lib, and (#ifdef HAVE_SPLIT_USR) /lib. Factor that logic out into a new helper macro, CONF_DIRS_NULSTR. --- Realized when defining the Nth instance of this for logind.conf.d that it really ought to have a common definition. src/binfmt/binfmt.c | 10 +- src/modules-load/modules-load.c | 10 +- src/shared/macro.h | 15 +++ src/sysctl/sysctl.c | 10 +- src/sysusers/sysusers.c | 10 +- src/tmpfiles/tmpfiles.c | 10 +- 6 files changed, 20 insertions(+), 45 deletions(-) diff --git a/src/binfmt/binfmt.c b/src/binfmt/binfmt.c index c1c1522..0a15faf 100644 --- a/src/binfmt/binfmt.c +++ b/src/binfmt/binfmt.c @@ -36,15 +36,7 @@ #include fileio.h #include build.h -static const char conf_file_dirs[] = -/etc/binfmt.d\0 -/run/binfmt.d\0 -/usr/local/lib/binfmt.d\0 -/usr/lib/binfmt.d\0 -#ifdef HAVE_SPLIT_USR -/lib/binfmt.d\0 -#endif -; +static const char conf_file_dirs[] = CONF_DIRS_NULSTR(binfmt); static int delete_rule(const char *rule) { _cleanup_free_ char *x = NULL, *fn = NULL; diff --git a/src/modules-load/modules-load.c b/src/modules-load/modules-load.c index c77b092..84ae337 100644 --- a/src/modules-load/modules-load.c +++ b/src/modules-load/modules-load.c @@ -38,15 +38,7 @@ static char **arg_proc_cmdline_modules = NULL; -static const char conf_file_dirs[] = -/etc/modules-load.d\0 -/run/modules-load.d\0 -/usr/local/lib/modules-load.d\0 -/usr/lib/modules-load.d\0 -#ifdef HAVE_SPLIT_USR -/lib/modules-load.d\0 -#endif -; +static const char conf_file_dirs[] = CONF_DIRS_NULSTR(modules-load); static void systemd_kmod_log(void *data, int priority, const char *file, int line, const char *fn, const char *format, va_list args) { diff --git a/src/shared/macro.h b/src/shared/macro.h index 9ee332c..6d4712c 100644 --- a/src/shared/macro.h +++ b/src/shared/macro.h @@ -384,6 +384,21 @@ do { \ _found; \ }) +/* Return a nulstr for a standard cascade of configuration directories, + * suitable to pass to conf_files_list_nulstr or config_parse_many. */ +#define CONF_DIRS_NULSTR(n) \ +/etc/ n .d\0 \ +/run/ n .d\0 \ +/usr/local/lib/ n .d\0 \ +/usr/lib/ n .d\0 \ +CONF_DIR_SPLIT_USR(n) + +#ifdef HAVE_SPLIT_USR +#define CONF_DIR_SPLIT_USR(n) /lib/ n .d\0 +#else +#define CONF_DIR_SPLIT_USR(n) +#endif + /* Define C11 thread_local attribute even on older gcc compiler * version */ #ifndef thread_local diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c index 809e59b..edebe50 100644 --- a/src/sysctl/sysctl.c +++ b/src/sysctl/sysctl.c @@ -38,15 +38,7 @@ static char **arg_prefixes = NULL; -static const char conf_file_dirs[] = -/etc/sysctl.d\0 -/run/sysctl.d\0 -/usr/local/lib/sysctl.d\0 -/usr/lib/sysctl.d\0 -#ifdef HAVE_SPLIT_USR -/lib/sysctl.d\0 -#endif -; +static const char conf_file_dirs[] = CONF_DIRS_NULSTR(sysctl); static char* normalize_sysctl(char *s) { char *n; diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c index 9b9be96..df585c1 100644 --- a/src/sysusers/sysusers.c +++ b/src/sysusers/sysusers.c @@ -67,15 +67,7 @@ typedef struct Item { static char *arg_root = NULL; -static const char conf_file_dirs[] = -/etc/sysusers.d\0 -/run/sysusers.d\0 -/usr/local/lib/sysusers.d\0 -/usr/lib/sysusers.d\0 -#ifdef HAVE_SPLIT_USR -/lib/sysusers.d\0 -#endif -; +static const char conf_file_dirs[] = CONF_DIRS_NULSTR(sysusers); static Hashmap *users = NULL, *groups = NULL; static Hashmap *todo_uids = NULL, *todo_gids = NULL; diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c index 1e4675f..23fd6ca 100644 --- a/src/tmpfiles/tmpfiles.c +++ b/src/tmpfiles/tmpfiles.c @@ -117,15 +117,7 @@ static char **arg_include_prefixes = NULL; static char **arg_exclude_prefixes = NULL; static char *arg_root = NULL; -static const char conf_file_dirs[] = -/etc/tmpfiles.d\0 -/run/tmpfiles.d\0 -/usr/local/lib/tmpfiles.d\0 -/usr/lib/tmpfiles.d\0 -#ifdef HAVE_SPLIT_USR -/lib/tmpfiles.d\0 -#endif -; +static const char conf_file_dirs[] = CONF_DIRS_NULSTR(tmpfiles); #define MAX_DEPTH 256 -- 2.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] logind: Support logind.conf.d directories in the usual search paths
This makes it possible to drop in logind configuration snippets from a package or other configuration management mechanism. Add documentation to the header of /etc/logind.conf pointing the user at /etc/logind.conf.d/*.conf. Introduce a new helper, conf_parse_many, to parse configuration files in a search path. --- Revised to keep /etc/systemd/logind.conf around, and to prefer the entire series of conf.d directories over /etc/systemd/logind.conf, as suggested by Lennart at http://lists.freedesktop.org/archives/systemd-devel/2014-October/024122.html If this approach looks sensible, I'll send further patches for various other tools with configuration files, such as journald and timesyncd; however, I wanted to establish the pattern and the common helper function first. With the config_parse_many helper, further changes like this should only require a one-line change to the actual tools, plus documentation. man/logind.conf.xml | 29 ++--- src/login/logind.c | 9 + src/login/logind.conf| 3 +++ src/shared/conf-parser.c | 32 src/shared/conf-parser.h | 8 5 files changed, 74 insertions(+), 7 deletions(-) diff --git a/man/logind.conf.xml b/man/logind.conf.xml index d245bf4..70ca837 100644 --- a/man/logind.conf.xml +++ b/man/logind.conf.xml @@ -44,18 +44,41 @@ refnamediv refnamelogind.conf/refname -refpurposeLogin manager configuration file/refpurpose +refpurposeLogin manager configuration files/refpurpose /refnamediv refsynopsisdiv parafilename/etc/systemd/logind.conf/filename/para + parafilename/etc/systemd/logind.conf.d/*.conf/filename/para + parafilename/run/systemd/logind.conf.d/*.conf/filename/para + parafilename/usr/lib/systemd/logind.conf.d/*.conf/filename/para /refsynopsisdiv refsect1 titleDescription/title -paraThis file configures various parameters of the systemd login manager, citerefentryrefentrytitlesystemd-logind.service/refentrytitlemanvolnum8/manvolnum/citerefentry./para - +paraThese files configure various parameters of the systemd login manager, citerefentryrefentrytitlesystemd-logind.service/refentrytitlemanvolnum8/manvolnum/citerefentry./para + +paraEach configuration file shall be named in the style of +filenamereplaceablefilename/replaceable.conf/filename. +Files in filename/etc//filename override files with the +same name in filename/usr/lib//filename and +filename/run//filename. Files in +filename/run//filename override files with the same name in +filename/usr/lib//filename. Packages should install their +configuration files in filename/usr/lib//filename. Files in +filename/etc//filename are reserved for the local +administrator, who may use this logic to override the +configuration files installed by vendor packages. All +configuration files are sorted by their filename in +lexicographic order, regardless of which of the directories +they reside in. If multiple files specify the same option, the +entry in the file with the lexicographically latest name will +be applied; entries in any filenamelogind.conf.d/filename +file override entries in +filename/etc/systemd/logind.conf/filename. It is +recommended to prefix all filenames with a two-digit number and +a dash, to simplify the ordering of the files./para /refsect1 refsect1 diff --git a/src/login/logind.c b/src/login/logind.c index 8f00c46..69b219d 100644 --- a/src/login/logind.c +++ b/src/login/logind.c @@ -1171,10 +1171,11 @@ int manager_run(Manager *m) { static int manager_parse_config_file(Manager *m) { assert(m); -return config_parse(NULL, /etc/systemd/logind.conf, NULL, -Login\0, -config_item_perf_lookup, logind_gperf_lookup, -false, false, true, m); +return config_parse_many(/etc/systemd/logind.conf, + CONF_DIRS_NULSTR(systemd/logind.conf), + Login\0, + config_item_perf_lookup, logind_gperf_lookup, + false, m); } int main(int argc, char *argv[]) { diff --git a/src/login/logind.conf b/src/login/logind.conf index 4608a2c..6b1943a 100644 --- a/src/login/logind.conf +++ b/src/login/logind.conf @@ -5,6 +5,9 @@ # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # +# You can override the
Re: [systemd-devel] [PATCHv2] logind: Support logind.conf.d directories in the usual search paths
On Mon, Oct 20, 2014 at 08:48:01PM +0200, Lennart Poettering wrote: On Mon, 20.10.14 11:28, j...@joshtriplett.org (j...@joshtriplett.org) wrote: I'd really prefer if we'd keep things in logind.conf and just provide the option of using logind.conf.d. This would be similar to unit files, where the unit files are where the beef is and .d/ is just a way to override/extend is. THe man page of logind.conf should reference the ability that .d/ files are supported, but that should be it for the documentation. We should really try to not to be too surprising here for admins which tend to expect one configuration file, not many. The main awkwardness there is that /etc/logind.conf, as a file in /etc, should be parsed *after* /usr/lib/systemd/logind.conf.d/ and *before* /etc/systemd/logind.conf.d/ , which breaks the usual logic to load all files in order with files in /etc overriding files in /usr. Well, as for units the main file should be read first (taking the /usr+/etc override logic into account), and only then we should read the .d/ drop-ins (individually following the /usr+/etc override logic). THis is what we do for unit files too. .d/ in this context really are supposed to be for overrding and extending, and hence reading the .d/ snippets in /usr after the main confi file from /etc is the right thing to do I believe. Ultimately the difference really shouldn#t matter too much I think. After all the version in /usr is for vendor defaults, and the stuff in /etc for user overrides. .d/ are for overrding hence mostly make sense in /etc only really, and should be the total exception in /usr. OK, if you're fine with /usr/lib/systemd/logind.conf.d/*.conf overriding /etc/logind.conf, then the patch gets *really* simple, and I'll submit v3 soon. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] logind: Support logind.conf.d directories in the usual search paths
On Fri, Oct 17, 2014 at 08:40:48AM +0300, Mantas Mikulėnas wrote: On Fri, Oct 17, 2014 at 7:29 AM, Josh Triplett j...@joshtriplett.org wrote: This makes it possible to drop in logind configuration snippets from a package or other configuration management mechanism. I'm still very curious what packages would need to install drop-ins for logind? Configuration packages, metapackages, configuration management systems, etc. Introduce a new helper, conf_parse_many, to parse configuration files in a search path. systemd now installs /usr/lib/systemd/logind.conf.d/50-default.conf rather than /etc/systemd/logind.conf . Distributions should migrate existing modified versions of /etc/systemd/logind.conf to /etc/systemd/logind.conf.d/50-default.conf . Sounds like unnecessary shuffling things around... It's the same process previously followed for /etc/modules moving to /etc/modules-load.d, for instance. For systemd, are git format-patch -M patches (with git-style renames rather than whole-file deletion/insertions) acceptable for mailing list review? That format makes renames much easier to review. I'm sure the patches are applied using `git am`, so that should work fine. That was my hope as well. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] logind: Support /etc/systemd/logind.conf.d/*.conf
This makes it possible to drop in configuration file snippets from a package or other configuration management mechanism. --- man/logind.conf.xml | 4 +++- src/login/logind.c | 21 + src/shared/conf-parser.c | 19 +++ src/shared/conf-parser.h | 7 +++ 4 files changed, 46 insertions(+), 5 deletions(-) diff --git a/man/logind.conf.xml b/man/logind.conf.xml index 8ba9523..836f307 100644 --- a/man/logind.conf.xml +++ b/man/logind.conf.xml @@ -44,17 +44,19 @@ refnamediv refnamelogind.conf/refname +refnamelogind.conf.d/refname refpurposeLogin manager configuration file/refpurpose /refnamediv refsynopsisdiv parafilename/etc/systemd/logind.conf/filename/para + parafilename/etc/systemd/logind.conf.d/*.conf/filename/para /refsynopsisdiv refsect1 titleDescription/title -paraThis file configures various parameters of the systemd login manager, citerefentryrefentrytitlesystemd-logind.service/refentrytitlemanvolnum8/manvolnum/citerefentry./para +paraThese files configures various parameters of the systemd login manager, citerefentryrefentrytitlesystemd-logind.service/refentrytitlemanvolnum8/manvolnum/citerefentry./para /refsect1 diff --git a/src/login/logind.c b/src/login/logind.c index 8f00c46..1feb251 100644 --- a/src/login/logind.c +++ b/src/login/logind.c @@ -29,6 +29,7 @@ #include sd-daemon.h #include strv.h +#include conf-files.h #include conf-parser.h #include mkdir.h #include bus-util.h @@ -1169,12 +1170,24 @@ int manager_run(Manager *m) { } static int manager_parse_config_file(Manager *m) { +_cleanup_strv_free_ char **filenames = NULL; +int r; + assert(m); -return config_parse(NULL, /etc/systemd/logind.conf, NULL, -Login\0, -config_item_perf_lookup, logind_gperf_lookup, -false, false, true, m); +r = conf_files_list(filenames, .conf, NULL, /etc/systemd/logind.conf.d, NULL); +if (r 0) +return r; + +r = config_parse(NULL, /etc/systemd/logind.conf, NULL, Login\0, + config_item_perf_lookup, logind_gperf_lookup, + false, false, true, m); +if (r 0) +return r; + +return config_parse_many(filenames, Login\0, + config_item_perf_lookup, logind_gperf_lookup, + false, m); } int main(int argc, char *argv[]) { diff --git a/src/shared/conf-parser.c b/src/shared/conf-parser.c index ee6de65..54bd642 100644 --- a/src/shared/conf-parser.c +++ b/src/shared/conf-parser.c @@ -430,6 +430,25 @@ int config_parse(const char *unit, return 0; } +/* Parse each config file, if it exists. */ +int config_parse_many(char **filenames, + const char *sections, + ConfigItemLookup lookup, + const void *table, + bool relaxed, + void *userdata) { +char **fn; +int r; + +STRV_FOREACH(fn, filenames) { +r = config_parse(NULL, *fn, NULL, sections, lookup, table, relaxed, false, true, userdata); +if (r 0) +return r; +} + +return 0; +} + #define DEFINE_PARSER(type, vartype, conv_func) \ int config_parse_##type(const char *unit, \ const char *filename, \ diff --git a/src/shared/conf-parser.h b/src/shared/conf-parser.h index 62f2a01..37eee55 100644 --- a/src/shared/conf-parser.h +++ b/src/shared/conf-parser.h @@ -92,6 +92,13 @@ int config_parse(const char *unit, bool warn, void *userdata); +int config_parse_many(char **filenames, + const char *sections, /* nulstr */ + ConfigItemLookup lookup, + const void *table, + bool relaxed, + void *userdata); + /* Generic parsers */ int config_parse_int(const char *unit, const char *filename, unsigned line, const char *section, unsigned section_line, const char *lvalue, int ltype, const char *rvalue, void *data, void *userdata); int config_parse_unsigned(const char *unit, const char *filename, unsigned line, const char *section, unsigned section_line, const char *lvalue, int ltype, const char *rvalue, void *data, void *userdata); -- 2.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] logind: Support /etc/systemd/logind.conf.d/*.conf
On Thu, Oct 16, 2014 at 03:36:57PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Oct 16, 2014 at 12:27:21PM +0200, Josh Triplett wrote: This makes it possible to drop in configuration file snippets from a package or other configuration management mechanism. What kind of settings would you install in this way? In my case, I plan to have one of my personal configuration packages install an /etc/systemd/logind.conf.d/lid.conf that contains: [Login] HandleLidSwitch=lock - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] logind: Support /etc/systemd/logind.conf.d/*.conf
On Thu, Oct 16, 2014 at 09:42:50AM -0400, Rahul Sundaram wrote: On Thu, Oct 16, 2014 at 6:27 AM, Josh Triplett wrote: This makes it possible to drop in configuration file snippets from a package or other configuration management mechanism. Shouldn't those go into /usr according to http://0pointer.net/blog/projects/stateless.html Fair enough, I can trivially have it check /usr/lib/systemd/logind.conf.d/*.conf as well. Will do in v2. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2] logind: Support logind.conf.d directories in the usual search paths
This makes it possible to drop in logind configuration snippets from a package or other configuration management mechanism. Introduce a new helper, conf_parse_many, to parse configuration files in a search path. systemd now installs /usr/lib/systemd/logind.conf.d/50-default.conf rather than /etc/systemd/logind.conf . Distributions should migrate existing modified versions of /etc/systemd/logind.conf to /etc/systemd/logind.conf.d/50-default.conf . Move the logind.conf manpage to logind.conf.d, update it to document the search paths, and update all references to it. --- v2: Updated to use the usual search path mechanism and directories. For systemd, are git format-patch -M patches (with git-style renames rather than whole-file deletion/insertions) acceptable for mailing list review? That format makes renames much easier to review. Makefile-man.am | 4 +- Makefile.am | 5 +- man/loginctl.xml | 2 +- man/logind.conf.d.xml| 381 +++ man/logind.conf.xml | 359 - man/nss-myhostname.xml | 2 +- man/pam_systemd.xml | 2 +- man/systemd-inhibit.xml | 4 +- man/systemd-logind.service.xml | 4 +- src/login/50-default.conf| 29 +++ src/login/logind.c | 17 +- src/login/logind.conf| 29 --- src/shared/conf-parser.c | 25 +++ src/shared/conf-parser.h | 7 + units/org.freedesktop.login1.busname | 2 +- units/systemd-logind.service.in | 2 +- 16 files changed, 469 insertions(+), 405 deletions(-) create mode 100644 man/logind.conf.d.xml delete mode 100644 man/logind.conf.xml create mode 100644 src/login/50-default.conf delete mode 100644 src/login/logind.conf diff --git a/Makefile-man.am b/Makefile-man.am index a13e948..f28eccd 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -1096,7 +1096,7 @@ endif if ENABLE_LOGIND MANPAGES += \ man/loginctl.1 \ - man/logind.conf.5 \ + man/logind.conf.d.5 \ man/systemd-logind.service.8 MANPAGES_ALIAS += \ man/systemd-logind.8 @@ -1547,7 +1547,7 @@ EXTRA_DIST += \ man/localectl.xml \ man/localtime.xml \ man/loginctl.xml \ - man/logind.conf.xml \ + man/logind.conf.d.xml \ man/machine-id.xml \ man/machine-info.xml \ man/machinectl.xml \ diff --git a/Makefile.am b/Makefile.am index e52db17..e048d83 100644 --- a/Makefile.am +++ b/Makefile.am @@ -95,6 +95,7 @@ sysusersdir=$(prefix)/lib/sysusers.d sysctldir=$(prefix)/lib/sysctl.d binfmtdir=$(prefix)/lib/binfmt.d modulesloaddir=$(prefix)/lib/modules-load.d +logindconfdir=$(prefix)/lib/logind.conf.d networkdir=$(rootprefix)/lib/systemd/network pkgincludedir=$(includedir)/systemd systemgeneratordir=$(rootlibexecdir)/system-generators @@ -5361,8 +5362,8 @@ dist_dbussystemservice_DATA += \ dist_dbuspolicy_DATA += \ src/login/org.freedesktop.login1.conf -dist_pkgsysconf_DATA += \ - src/login/logind.conf +dist_logindconf_DATA = \ + src/login/50-default.conf polkitpolicy_files += \ src/login/org.freedesktop.login1.policy diff --git a/man/loginctl.xml b/man/loginctl.xml index 749db92..b2eaea4 100644 --- a/man/loginctl.xml +++ b/man/loginctl.xml @@ -446,7 +446,7 @@ citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry, citerefentryrefentrytitlesystemctl/refentrytitlemanvolnum1/manvolnum/citerefentry, citerefentryrefentrytitlesystemd-logind.service/refentrytitlemanvolnum8/manvolnum/citerefentry, - citerefentryrefentrytitlelogind.conf/refentrytitlemanvolnum5/manvolnum/citerefentry + citerefentryrefentrytitlelogind.conf.d/refentrytitlemanvolnum5/manvolnum/citerefentry /para /refsect1 diff --git a/man/logind.conf.d.xml b/man/logind.conf.d.xml new file mode 100644 index 000..1c34017 --- /dev/null +++ b/man/logind.conf.d.xml @@ -0,0 +1,381 @@ +?xml version='1.0'? !--*-nxml-*-- +?xml-stylesheet type=text/xsl href=http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl;? +!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN +http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; + +!-- + This file is part of systemd. + + Copyright 2010 Lennart Poettering + + systemd is free software; you can redistribute it and/or modify it + under the terms of the GNU Lesser General Public License as published by + the Free Software Foundation; either version 2.1 of the License, or + (at your option) any later version. + + systemd is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Re: [systemd-devel] [PATCH] journalctl: add --utc option
On Thu, Oct 02, 2014 at 09:36:46AM +0200, Jan Synacek wrote: Introduce option to display time in UTC. Does TZ=UTC journalctl not do the right thing? A quick test here suggests that it does. That seems preferable to teaching individual tools to special-case UTC. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: add --utc option
On Thu, Oct 02, 2014 at 09:11:39PM +0200, Lennart Poettering wrote: On Thu, 02.10.14 11:56, Josh Triplett (j...@joshtriplett.org) wrote: On Thu, Oct 02, 2014 at 09:36:46AM +0200, Jan Synacek wrote: Introduce option to display time in UTC. Does TZ=UTC journalctl not do the right thing? A quick test here suggests that it does. That seems preferable to teaching individual tools to special-case UTC. Not sure i agree. --utc really should only have an effect on our own output, and that's a good thing. If you set $TZ you end up changing much much more, for example the logic of glibc's own syslog() and what it passes on, and we shouldn't influence that. True, but in the case of journalctl, which just queries and outputs journal data, what would TZ=UTC affect that you *wouldn't* want? journalctl shouldn't be calling syslog(). - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-resolved, multi-home DNS resolution, VPNs, and privacy
The documentation for systemd-resolved says it sends DNS queries on all interfaces. That seems like a bug for privacy and security reasons: I don't necessarily want a query for foo.internalhost.com going anywhere other than my VPN for internalhost.com, and if I run a VPN for privacy purposes then I don't want *anything* other than the VPN itself to send traffic over a non-VPN interface. Any way we could fix that while retaining the works out of the box behavior? - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: add molly-guard functionality
On Mon, Aug 25, 2014 at 07:19:47PM +0200, Lennart Poettering wrote: On Sat, 23.08.14 19:26, Josh Triplett (j...@joshtriplett.org) wrote: Rather than requiring a third-party tool for this, systemctl should handle this natively. This has been proposed before, but I sounds awfully random to me to have in systemd. I am pretty sure this should be an add-on, but not something we should support out-of-the-box. I wouldn't argue that it's something we should *enable* by default, just something to have available and enableable (perhaps via system.conf). Related to that, would you be willing to take patches for separate tiny binaries for shutdown/poweroff/etc, so that they don't depend on argv[0] to decide what to do? That would make it easier to do things like diverting /sbin/poweroff to /sbin/poweroff.real and putting a wrapper in /sbin/poweroff. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] TODO: add molly-guard functionality
Rather than requiring a third-party tool for this, systemctl should handle this natively. --- TODO | 1 + 1 file changed, 1 insertion(+) diff --git a/TODO b/TODO index 0fcd3a0..aaf6444 100644 --- a/TODO +++ b/TODO @@ -441,6 +441,7 @@ Features: - Something is wrong with symlink handling of autovt@.service in systemctl list-unit-files - better error message if you run systemctl without systemd running - systemctl status output should should include list of triggering units and their status + - add molly-guard functionality: prompt for hostname if interactively shutting down a remote system (running as child of ssh) * unit install: - systemctl mask should find all names by which a unit is accessible -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
[Responding to this version because the latest thread hasn't appeared in the mbox archives yet. The comments apply equally well to the latest version, Add DEPLOYMENT to hostnamectl.] On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote: +static bool valid_environment(const char *environment) { + +assert(environment); + +return nulstr_contains( +development\0 +staging\0 +production\0, +environment); +} Can we please *not* attempt to limit or standardize this particular set of machine roles? As already demonstrated in the previous thread, people have all sorts of staged deployment strategies. Furthermore, the concept of a machine role shouldn't be limited to service deployment strategies. Debian has a file /etc/debian_chroot, used to describe the nature of a chroot environment, such as i386 cross for a 32-bit build chroot, or similar. The default prompt then incorporates that string. This seems quite similar, and I'd love to see a standardized mechanism for that kind of string. Rather than limiting this list to a few specific tokens, could we just provide a MachineRole or similar, which accepts a short freeform text string? Then, a staged deployment system could use this for development/staging/production/validation/replication/blue/whatever, while another type of system can use its own tokens here. As general guidance, we could say something like MachineRole should consist of a space-separated series of printable tokens, such as 'production' or 'staging'.. This also allows MachineRole to contain something like staging foobranch, for instance, which indicates a staging server that's part of the experimental parallel foobranch infrastructure. This would still allow the role string to serve its primary functions: querying it to check for particular values used within an organization, or inserting it into prompts, window titles, and similar. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
On Wed, Jul 09, 2014 at 01:16:04AM +, Jóhann B. Guðmundsson wrote: On 07/09/2014 01:05 AM, j...@joshtriplett.org wrote: On Tue, Jul 08, 2014 at 10:45:11PM +, Jóhann B. Guðmundsson wrote: On 07/08/2014 10:45 PM, Josh Triplett wrote: [Responding to this version because the latest thread hasn't appeared in the mbox archives yet. The comments apply equally well to the latest version, Add DEPLOYMENT to hostnamectl.] On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote: +static bool valid_environment(const char *environment) { + +assert(environment); + +return nulstr_contains( +development\0 +staging\0 +production\0, +environment); +} Can we please*not* attempt to limit or standardize this particular set of machine roles? As already demonstrated in the previous thread, people have all sorts of staged deployment strategies. Furthermore, the concept of a machine role shouldn't be limited to service deployment strategies. Roles != the environment they run in. I'm not trying to bikeshed over the naming of the variable itself. I'm arguing that standardizing this particular bit of metadata won't work well when so many different deployment strategies exist. Thus, rather than having a fixed set of keywords, I'd propose simply saying this contains keywords, and leaving the specific keywords up to the admin. If you attempt to standardize production/development/staging, you'll either end up with a model that only works for a small subset of deployments, or you'll end up adding twelve more keywords, at which point you might as well have just said use whatever keyword you like. The 4 tier covers the majority of the models since more or less the entire internet recommend three tier model including M$ [1] Anyone wanting to extend that further can do so using the PRETTY_HOSTNAME= PRETTY_HOSTNAME does not equate to description, and in any case is not the same thing as a deployment environment. This patch is very specific to deployment environment and to solve a very specific long standing problem and to achieve that we need to a standardize, if we dont we can just as well drop this patch since in the long run we cannot introduce something like ConditionDeployment= like David mentioned and it kinda defeat's my purpose working in this in the firsplace... Distribution unit files will never use ConditionDeployment; only admin-created or admin-modified unit files will. Given that, it will work perfectly without a standardized set of names. Just specify that DEPLOYMENT contains a keyword *such as* (but not limited to) production or development, and then state that ConditionDeployment can specify a keyword. That will work perfectly without limiting the set of possible keywords. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH rebased] Use strlen even for constant strings
On Sun, Mar 16, 2014 at 02:56:10PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Sat, Mar 15, 2014 at 11:40:07AM -0700, Josh Triplett wrote: GCC optimizes strlen(string constant) to a constant, even with -O0. Thus, replace patterns like sizeof(string constant)-1 with strlen(string constant) where possible, for clarity. In particular, for expressions intended to add up the lengths of components going into a string, this often makes it clearer that the expression counts the trailing '\0' exactly once, by putting the +1 for the '\0' at the end of the expression, rather than hidden in a sizeof in the middle of the expression. Applied, thanks. On Sat, Mar 15, 2014 at 05:37:49AM +0100, Zbigniew Jędrzejewski-Szmek wrote: strlen() is indeed much nicer. Unfortunately it stopped applying cleanly... Could you rebase this? Done; git rebased it automatically with no conflicts. (am -3 might work in the future for patches that trivially rebase.) I tried that, but for some reason it didn't seem to work. Maybe your patch was missing the headers necessayr for -3? Full commits have all those headers (the index lines with partial hashes on them), but possibly I'm overestimating the capabilities of -3. In any case, git rebase automatically did the three-way merge. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH rebased] Use strlen even for constant strings
GCC optimizes strlen(string constant) to a constant, even with -O0. Thus, replace patterns like sizeof(string constant)-1 with strlen(string constant) where possible, for clarity. In particular, for expressions intended to add up the lengths of components going into a string, this often makes it clearer that the expression counts the trailing '\0' exactly once, by putting the +1 for the '\0' at the end of the expression, rather than hidden in a sizeof in the middle of the expression. --- On Sat, Mar 15, 2014 at 05:37:49AM +0100, Zbigniew Jędrzejewski-Szmek wrote: strlen() is indeed much nicer. Unfortunately it stopped applying cleanly... Could you rebase this? Done; git rebased it automatically with no conflicts. (am -3 might work in the future for patches that trivially rebase.) src/core/dbus.c| 2 +- src/core/service.c | 2 +- src/journal/journald-server.c | 2 +- src/journal/journald-syslog.c | 2 +- src/libsystemd/sd-bus/bus-kernel.c | 4 ++-- src/libsystemd/sd-bus/bus-socket.c | 4 ++-- src/libsystemd/sd-bus/bus-track.c | 2 +- src/shared/cgroup-util.c | 2 +- src/shared/unit-name.c | 2 +- src/shared/util.c | 2 +- src/sysctl/sysctl.c| 2 +- src/systemctl/systemctl.c | 40 +++--- src/udev/udev-rules.c | 14 ++--- 13 files changed, 40 insertions(+), 40 deletions(-) diff --git a/src/core/dbus.c b/src/core/dbus.c index 03f3738..72f36bd 100644 --- a/src/core/dbus.c +++ b/src/core/dbus.c @@ -953,7 +953,7 @@ static int bus_init_private(Manager *m) { return 0; strcpy(sa.un.sun_path, /run/systemd/private); -salen = offsetof(union sockaddr_union, un.sun_path) + sizeof(/run/systemd/private) - 1; +salen = offsetof(union sockaddr_union, un.sun_path) + strlen(/run/systemd/private); } else { size_t left = sizeof(sa.un.sun_path); char *p = sa.un.sun_path; diff --git a/src/core/service.c b/src/core/service.c index 121ddec..41b95ab 100644 --- a/src/core/service.c +++ b/src/core/service.c @@ -361,7 +361,7 @@ static int service_arm_timer(Service *s, usec_t usec) { static char *sysv_translate_name(const char *name) { char *r; -r = new(char, strlen(name) + sizeof(.service)); +r = new(char, strlen(name) + strlen(.service) + 1); if (!r) return NULL; diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c index f0117e7..5befe93 100644 --- a/src/journal/journald-server.c +++ b/src/journal/journald-server.c @@ -686,7 +686,7 @@ static void dispatch_message_real( #ifdef HAVE_SELINUX if (use_selinux()) { if (label) { -x = alloca(sizeof(_SELINUX_CONTEXT=) + label_len); +x = alloca(strlen(_SELINUX_CONTEXT=) + label_len + 1); *((char*) mempcpy(stpcpy(x, _SELINUX_CONTEXT=), label, label_len)) = 0; IOVEC_SET_STRING(iovec[n++], x); diff --git a/src/journal/journald-syslog.c b/src/journal/journald-syslog.c index cbb944f..fee7d91 100644 --- a/src/journal/journald-syslog.c +++ b/src/journal/journald-syslog.c @@ -46,7 +46,7 @@ static void forward_syslog_iovec(Server *s, const struct iovec *iovec, unsigned .msg_iovlen = n_iovec, .msg_name = sa, .msg_namelen = offsetof(union sockaddr_union, un.sun_path) - + sizeof(/run/systemd/journal/syslog) - 1, + + strlen(/run/systemd/journal/syslog), }; struct cmsghdr *cmsg; union { diff --git a/src/libsystemd/sd-bus/bus-kernel.c b/src/libsystemd/sd-bus/bus-kernel.c index 80ef15b..5c955f4 100644 --- a/src/libsystemd/sd-bus/bus-kernel.c +++ b/src/libsystemd/sd-bus/bus-kernel.c @@ -1390,7 +1390,7 @@ int bus_kernel_create_starter(const char *bus, const char *name, BusNamePolicy * assert(bus); assert(name); -p = alloca(sizeof(/dev/kdbus/) - 1 + DECIMAL_STR_MAX(uid_t) + 1 + strlen(bus) + sizeof(/bus)); +p = alloca(strlen(/dev/kdbus/) + DECIMAL_STR_MAX(uid_t) + 1 + strlen(bus) + strlen(/bus) + 1); sprintf(p, /dev/kdbus/%lu-%s/bus, (unsigned long) getuid(), bus); fd = open(p, O_RDWR|O_NOCTTY|O_CLOEXEC); @@ -1502,7 +1502,7 @@ int bus_kernel_create_monitor(const char *bus) { assert(bus); -p = alloca(sizeof(/dev/kdbus/) - 1 + DECIMAL_STR_MAX(uid_t) + 1 + strlen(bus) + sizeof(/bus)); +p = alloca(strlen(/dev/kdbus/) + DECIMAL_STR_MAX(uid_t) + 1 + strlen(bus) + strlen(/bus) + 1); sprintf(p, /dev/kdbus/%lu-%s/bus, (unsigned long) getuid(), bus); fd = open(p, O_RDWR|O_NOCTTY|O_CLOEXEC); diff --git
Re: [systemd-devel] [PATCH] util: Rewrite in_charset to use strspn
On Wed, Mar 12, 2014 at 12:49:08AM +0100, Lennart Poettering wrote: Can you turn this into an inline function please? If it's that simple it sounds better to just make it an inline function in the .h file, instead of the .c file... Sure. Mind if I do that as a two-patch series? I prefer to avoid simultaneously changing code and moving it, since it makes the change diff less obvious. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] util: Make in_charset a static inline in util.h
With in_charset now reduced to a one-liner (plus asserts), make it a static inline. --- This applies on top of the previous patch simplifying in_charset. src/shared/util.c | 6 -- src/shared/util.h | 6 +- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/src/shared/util.c b/src/shared/util.c index 82326df..9f79409 100644 --- a/src/shared/util.c +++ b/src/shared/util.c @@ -920,12 +920,6 @@ char *delete_chars(char *s, const char *bad) { return s; } -bool in_charset(const char *s, const char* charset) { -assert(s); -assert(charset); -return s[strspn(s, charset)] == '\0'; -} - char *file_in_same_dir(const char *path, const char *filename) { char *e, *r; size_t k; diff --git a/src/shared/util.h b/src/shared/util.h index c2bc977..0c8eb4b 100644 --- a/src/shared/util.h +++ b/src/shared/util.h @@ -529,7 +529,11 @@ char *strjoin(const char *x, ...) _sentinel_; bool is_main_thread(void); -bool in_charset(const char *s, const char* charset) _pure_; +static inline bool _pure_ in_charset(const char *s, const char* charset) { +assert(s); +assert(charset); +return s[strspn(s, charset)] == '\0'; +} int block_get_whole_disk(dev_t d, dev_t *ret); -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] backlight: Fix copy/paste error printing an unrelated error code
udev_device_get_sysattr_value returns NULL on failure, but doesn't provide an error code; thus, when printing an error from it, don't print an unrelated error code from a previous call. --- src/backlight/backlight.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c index 86f10cc..81470b3 100644 --- a/src/backlight/backlight.c +++ b/src/backlight/backlight.c @@ -322,7 +322,7 @@ int main(int argc, char *argv[]) { value = udev_device_get_sysattr_value(device, brightness); if (!value) { -log_error(Failed to read system attribute: %s, strerror(-r)); +log_error(Failed to read system attribute); return EXIT_FAILURE; } -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level
Some systems turn the backlight all the way off at the lowest levels. Clamp saved brightness to at least 1 or 5% of max_brightness. This avoids preserving an unreadably dim screen, which would otherwise force the user to disable state restoration. --- src/backlight/backlight.c | 39 +++ 1 file changed, 39 insertions(+) diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c index 81470b3..b776ab5 100644 --- a/src/backlight/backlight.c +++ b/src/backlight/backlight.c @@ -292,6 +292,7 @@ int main(int argc, char *argv[]) { if (streq(argv[1], load) shall_restore_state()) { _cleanup_free_ char *value = NULL; +const char *max_brightness_str; if (!validate_device(udev, device)) return EXIT_SUCCESS; @@ -306,6 +307,44 @@ int main(int argc, char *argv[]) { return EXIT_FAILURE; } +/* Some systems turn the backlight all the way off at the + * lowest levels. Clamp saved brightness to at least 1 or 5% + * of max_brightness. This avoids preserving an unreadably dim + * screen, which would otherwise force the user to disable + * state restoration. + */ +max_brightness_str = udev_device_get_sysattr_value(device, max_brightness); +if (!max_brightness_str) { +log_warning(Failed to read max_brightness attribute; not checking saved brightness); +} else { +unsigned long long brightness, max_brightness, new_brightness; + +r = safe_atollu(value, brightness); +if (r 0) { +log_error(Failed to parse brightness \%s\: %s, value, strerror(-r)); +return EXIT_FAILURE; +} + +r = safe_atollu(max_brightness_str, max_brightness); +if (r 0) { +log_error(Failed to parse max_brightness \%s\: %s, max_brightness_str, strerror(-r)); +return EXIT_FAILURE; +} + +new_brightness = MAX3(brightness, 1, max_brightness/20); +if (new_brightness != brightness) { +_cleanup_free_ char *old_value = value; + +value = asprintf(%llu, new_brightness); +if (!value) { +log_oom(); +return EXIT_FAILURE; +} + +log_warning(Saved brightness %s too low; increasing to %s, old_value, value); +} +} + r = udev_device_set_sysattr_value(device, brightness, value); if (r 0) { log_error(Failed to write system attribute: %s, strerror(-r)); -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] util: Rewrite in_charset to use strspn
This simplifies in_charset down to a one-liner, and allows for possible optimizations of strspn in libc. --- src/shared/util.c | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/src/shared/util.c b/src/shared/util.c index d28caae..82326df 100644 --- a/src/shared/util.c +++ b/src/shared/util.c @@ -921,16 +921,9 @@ char *delete_chars(char *s, const char *bad) { } bool in_charset(const char *s, const char* charset) { -const char *i; - assert(s); assert(charset); - -for (i = s; *i; i++) -if (!strchr(charset, *i)) -return false; - -return true; +return s[strspn(s, charset)] == '\0'; } char *file_in_same_dir(const char *path, const char *filename) { -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level
On Wed, Mar 12, 2014 at 03:32:47AM +0100, Lennart Poettering wrote: On Tue, 11.03.14 18:55, Josh Triplett (j...@joshtriplett.org) wrote: +/* Some systems turn the backlight all the way off at the + * lowest levels. Clamp saved brightness to at least 1 or 5% + * of max_brightness. This avoids preserving an unreadably dim + * screen, which would otherwise force the user to disable + * state restoration. + */ +max_brightness_str = udev_device_get_sysattr_value(device, max_brightness); +if (!max_brightness_str) { +log_warning(Failed to read max_brightness attribute; not checking saved brightness); +} else { We try to avoid unnnecessary {} for single-line if blocks, if we can... Even when the else block *does* need the braces? (Note that kernel style says to avoid braces on single-line blocks but always use braces on all branches of an if/else-if/else if any branch needs them.) Hmmm, could you maybe move the entire clamping thing into a function of its own? Maybe clamp_brightness(struct udev_device *d, char **brightness) or so, that simply patches the brightness string if it feels like it, otherwise leaves it unmodified? Sure. +unsigned long long brightness, max_brightness, new_brightness; Wow, you expect a lot of brightness levels! ;-) I'd just stick to unsigned here... Keeps it more readable... It's just two words (long long) and a couple of lls later, but OK. + +r = safe_atollu(value, brightness); +if (r 0) { +log_error(Failed to parse brightness \%s\: %s, value, strerror(-r)); +return EXIT_FAILURE; +} + +r = safe_atollu(max_brightness_str, max_brightness); +if (r 0) { +log_error(Failed to parse max_brightness \%s\: %s, max_brightness_str, strerror(-r)); +return EXIT_FAILURE; +} Hmm, I'd prefer if the whole clamping business would be non-fatal. i.e. it clamps if it can read the files and parse them, but if it can't it won't do anything... I thought about that, but it would have complicated the logic, and those kernel files should always be numbers anyway. However, with a move to a separate function, this gets easier with early return, so sure. +new_brightness = MAX3(brightness, 1, max_brightness/20); +if (new_brightness != brightness) { +_cleanup_free_ char *old_value = value; + +value = asprintf(%llu, new_brightness); asprintf() works differently... r = asprintf(value, %llu, new_brightness)... Gah, I fixed that and then managed to send the wrong patch, sorry. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2 1/2] backlight: Fix copy/paste error printing an unrelated error code
udev_device_get_sysattr_value returns NULL on failure, but doesn't provide an error code; thus, when printing an error from it, don't print an unrelated error code from a previous call. --- v2: Patch 1/2 unchanged from v1. src/backlight/backlight.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c index 86f10cc..81470b3 100644 --- a/src/backlight/backlight.c +++ b/src/backlight/backlight.c @@ -322,7 +322,7 @@ int main(int argc, char *argv[]) { value = udev_device_get_sysattr_value(device, brightness); if (!value) { -log_error(Failed to read system attribute: %s, strerror(-r)); +log_error(Failed to read system attribute); return EXIT_FAILURE; } -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level
Some systems turn the backlight all the way off at the lowest levels. Clamp saved brightness to at least 1 or 5% of max_brightness. This avoids preserving an unreadably dim screen, which would otherwise force the user to disable state restoration. --- v2: Send the right patch this time. Factor clamping into a separate function. Make failures in clamping non-fatal. Use unsigned rather than unsigned long long. src/backlight/backlight.c | 44 1 file changed, 44 insertions(+) diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c index 81470b3..44308e0 100644 --- a/src/backlight/backlight.c +++ b/src/backlight/backlight.c @@ -192,6 +192,48 @@ static bool validate_device(struct udev *udev, struct udev_device *device) { return true; } +/* Some systems turn the backlight all the way off at the lowest levels. + * clamp_brightness clamps the saved brightness to at least 1 or 5% of + * max_brightness. This avoids preserving an unreadably dim screen, which + * would otherwise force the user to disable state restoration. */ +static void clamp_brightness(struct udev_device *device, char **value) { +int r; +const char *max_brightness_str; +unsigned brightness, max_brightness, new_brightness; + +max_brightness_str = udev_device_get_sysattr_value(device, max_brightness); +if (!max_brightness_str) { +log_warning(Failed to read max_brightness attribute; not checking saved brightness); +return; +} + +r = safe_atou(*value, brightness); +if (r 0) { +log_warning(Failed to parse brightness \%s\: %s, *value, strerror(-r)); +return; +} + +r = safe_atou(max_brightness_str, max_brightness); +if (r 0) { +log_warning(Failed to parse max_brightness \%s\: %s, max_brightness_str, strerror(-r)); +return; +} + +new_brightness = MAX3(brightness, 1U, max_brightness/20); +if (new_brightness != brightness) { +char *old_value = *value; + +r = asprintf(value, %u, new_brightness); +if (r 0) { +log_warning(Failed to format new brightness: %s, strerror(-r)); +return; +} + +log_warning(Saved brightness %s too low; increasing to %s, old_value, *value); +free(old_value); +} +} + int main(int argc, char *argv[]) { _cleanup_udev_unref_ struct udev *udev = NULL; _cleanup_udev_device_unref_ struct udev_device *device = NULL; @@ -306,6 +348,8 @@ int main(int argc, char *argv[]) { return EXIT_FAILURE; } +clamp_brightness(device, value); + r = udev_device_set_sysattr_value(device, brightness, value); if (r 0) { log_error(Failed to write system attribute: %s, strerror(-r)); -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add avoid_cleanup macro to cancel _cleanup_ of a pointer
On Mon, Mar 10, 2014 at 04:44:02PM +0100, Lennart Poettering wrote: On Sat, 08.03.14 20:33, Josh Triplett (j...@joshtriplett.org) wrote: avoid_cleanup also returns a copy of the pointer, making it convenient to use at the point where initialization completes, to hand the constructed object off somewhere without freeing it. Change all NULL assignments tagged with /* avoid cleanup */ to use this instead. --- Seems like a common pattern, and this makes it more self-documenting. In particular, the use in systemctl.c's list_timers function now feels like a single logical operation of hand ownership of this object off to something else and don't clean it up. Hmmm, I am all for synctactic sugar, but I don't see the benefit of this one really... Especially given that that disabling cleanup is done different for different types... For example, disabling cleanup for an fd is by assigning -1... As far as I can tell, that's the *only* differing case. Everything else is a pointer and uses NULL. I would see benefit in this if we could maybe make this type-sensitive... not sure though if C would allow that? I at least cannot think of a way to do that? C11 allows it using _Generic, if you're willing to rely on that. __builtin_types_compatible_p and some casts could work too. But again, I think the only two cases are int and pointer. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add avoid_cleanup macro to cancel _cleanup_ of a pointer
avoid_cleanup also returns a copy of the pointer, making it convenient to use at the point where initialization completes, to hand the constructed object off somewhere without freeing it. Change all NULL assignments tagged with /* avoid cleanup */ to use this instead. --- Seems like a common pattern, and this makes it more self-documenting. In particular, the use in systemctl.c's list_timers function now feels like a single logical operation of hand ownership of this object off to something else and don't clean it up. src/shared/macro.h| 7 +++ src/systemctl/systemctl.c | 8 +++- src/timedate/timedated.c | 5 + src/tmpfiles/tmpfiles.c | 2 +- src/udev/udevadm-hwdb.c | 2 +- 5 files changed, 13 insertions(+), 11 deletions(-) diff --git a/src/shared/macro.h b/src/shared/macro.h index 08a036b..1e521bc 100644 --- a/src/shared/macro.h +++ b/src/shared/macro.h @@ -337,6 +337,13 @@ do { \ _found; \ }) +#define avoid_cleanup(p)\ +({ \ +typeof(p) _p = (p); \ +(p) = NULL; \ +_p; \ +}) + /* Define C11 thread_local attribute even on older gcc compiler * version */ #ifndef thread_local diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c index f395265..d7983d1 100644 --- a/src/systemctl/systemctl.c +++ b/src/systemctl/systemctl.c @@ -749,8 +749,8 @@ static int list_sockets(sd_bus *bus, char **args) { /* from this point on we will cleanup those socket_infos */ cs += c; -free(listening); -listening = triggered = NULL; /* avoid cleanup */ +free(avoid_cleanup(listening)); +avoid_cleanup(triggered); } qsort_safe(socket_infos, cs, sizeof(struct socket_info), @@ -979,10 +979,8 @@ static int list_timers(sd_bus *bus, char **args) { timer_infos[c++] = (struct timer_info) { .id = u-id, .next_elapse = m, -.triggered = triggered, +.triggered = avoid_cleanup(triggered), }; - -triggered = NULL; /* avoid cleanup */ } qsort_safe(timer_infos, c, sizeof(struct timer_info), diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c index d85ce57..0494d53 100644 --- a/src/timedate/timedated.c +++ b/src/timedate/timedated.c @@ -281,10 +281,7 @@ static char** get_ntp_services(void) { } } -i = r; -r = NULL; /* avoid cleanup */ - -return strv_uniq(i); +return strv_uniq(avoid_cleanup(r)); } static int context_read_ntp(Context *c, sd_bus *bus) { diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c index 6e36dc7..45f79e2 100644 --- a/src/tmpfiles/tmpfiles.c +++ b/src/tmpfiles/tmpfiles.c @@ -1261,7 +1261,7 @@ static int parse_line(const char *fname, unsigned line, const char *buffer) { return r; } -i = NULL; /* avoid cleanup */ +avoid_cleanup(i); return 0; } diff --git a/src/udev/udevadm-hwdb.c b/src/udev/udevadm-hwdb.c index 65cbf61..7b6e0af 100644 --- a/src/udev/udevadm-hwdb.c +++ b/src/udev/udevadm-hwdb.c @@ -219,7 +219,7 @@ static int trie_insert(struct trie *trie, struct trie_node *node, const char *se if (err) return err; -new_child = NULL; /* avoid cleanup */ +avoid_cleanup(new_child); break; } i += p; -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-backlight and backlight level 0
systemd-backlight saves backlight levels on shutdown, and restores them on startup. However, on some systems, backlight level 0 actually turns the backlight *off*; this can potentially make the system unusable. Complicating matters, on most systems, nothing pays attention to the brightness adjustment keys in text mode. I'd suggest one or both of the following two changes, to avoid a painful failure mode: - systemd-backlight should avoid saving/restoring a backlight level of 0, and have a minimum backlight level. (Possibly overridable via configuration, for people who *really* want to restore backlight level 0.) - Something ought to listen to the brightness keys (and perhaps other hotkeys) in pure text mode. systemd seems like a good place for such a something to live. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-backlight and backlight level 0
On Wed, Mar 05, 2014 at 06:59:27PM +0100, David Herrmann wrote: On Wed, Mar 5, 2014 at 6:46 PM, Josh Triplett j...@joshtriplett.org wrote: systemd-backlight saves backlight levels on shutdown, and restores them on startup. However, on some systems, backlight level 0 actually turns the backlight *off*; this can potentially make the system unusable. Complicating matters, on most systems, nothing pays attention to the brightness adjustment keys in text mode. I'd suggest one or both of the following two changes, to avoid a painful failure mode: - systemd-backlight should avoid saving/restoring a backlight level of 0, and have a minimum backlight level. (Possibly overridable via configuration, for people who *really* want to restore backlight level 0.) Never restoring val==0 seems fine to me. Likewise. - Something ought to listen to the brightness keys (and perhaps other hotkeys) in pure text mode. systemd seems like a good place for such a something to live. We cannot do that. It requires keymap-handling (as brightness keys are handled on the keysym, not keycode level) and this is exclusive territory of the compositor (or other foreground session controllers). Perhaps this will get fixed when we switch from kernel VTs to a userspace-managed console, then. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-backlight and backlight level 0
On Wed, Mar 05, 2014 at 07:10:51PM +0100, Lennart Poettering wrote: On Wed, 05.03.14 09:46, Josh Triplett (j...@joshtriplett.org) wrote: systemd-backlight saves backlight levels on shutdown, and restores them on startup. However, on some systems, backlight level 0 actually turns the backlight *off*; this can potentially make the system unusable. Complicating matters, on most systems, nothing pays attention to the brightness adjustment keys in text mode. I'd suggest one or both of the following two changes, to avoid a painful failure mode: - systemd-backlight should avoid saving/restoring a backlight level of 0, and have a minimum backlight level. (Possibly overridable via configuration, for people who *really* want to restore backlight level 0.) To deal with situations like this there's systemd.restore_state=0 on the kernel cmdline, see kernel-command-line(7). Yeah, I've seen that one; however, having to reboot the system and change the kernel command line to unbreak it seems less ideal than having the system avoid broken states to begin with. I could be convinced to fix brightness level 0 to 1 when restoring. But then again, I fear the next people will come then and say 1 is only marginally better than 0, i want the minimum to be 16!... Or even others saying Dude, I only got 3 brightness levels, and you took one away from me So I am not enthusiastic about the idea... Given the choice between maximum flexibility and never making the system unusable, I'll take the latter. Not that hard to make it configurable, if that proves necessary. On restore, I'd suggest reading max_brightness, and if the stored value falls under a threshold of ceil(max_brightness/SOME_DIVISOR), restore it to that value instead. (Ideally there should be some way to ask the driver what level of brightness will produce a non-zero value in actual_brightness, but no such mechanism seems to exist.) Does that sound reasonable? - Something ought to listen to the brightness keys (and perhaps other hotkeys) in pure text mode. systemd seems like a good place for such a something to live. That's definitely a job for the DE I am sure, so that can it do an OSD and all the other stuff. We do power button handling in logind only because what it does is relatively important and really close to the system lifecycle... But brightness keys (or volume keys..) are not close at all. I am really sure that that's for the DEs to handle, not us. DEs don't handle the text consoles. However, it does sound like this will have to wait for kmscon or equivalent. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-backlight and backlight level 0
On Wed, Mar 05, 2014 at 10:21:17PM +0100, David Herrmann wrote: On Wed, Mar 5, 2014 at 8:31 PM, Josh Triplett j...@joshtriplett.org wrote: On Wed, Mar 05, 2014 at 07:10:51PM +0100, Lennart Poettering wrote: On Wed, 05.03.14 09:46, Josh Triplett (j...@joshtriplett.org) wrote: systemd-backlight saves backlight levels on shutdown, and restores them on startup. However, on some systems, backlight level 0 actually turns the backlight *off*; this can potentially make the system unusable. Complicating matters, on most systems, nothing pays attention to the brightness adjustment keys in text mode. I'd suggest one or both of the following two changes, to avoid a painful failure mode: - systemd-backlight should avoid saving/restoring a backlight level of 0, and have a minimum backlight level. (Possibly overridable via configuration, for people who *really* want to restore backlight level 0.) To deal with situations like this there's systemd.restore_state=0 on the kernel cmdline, see kernel-command-line(7). Yeah, I've seen that one; however, having to reboot the system and change the kernel command line to unbreak it seems less ideal than having the system avoid broken states to begin with. I'd expect this to be set on the recovery boot option. At I know some distros always provide two boot entries and to me this seems like the right place to set it. Not a bad idea, but rather than requiring the addition of an extra option (or potentially more than one, if other parts of systemd might want to be more conservative on recovery as well), how about having systemd-backlight treat single as systemd.restore_state=0? - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: Simple conditionals in tmpfiles
On Sat, Mar 01, 2014 at 03:03:17PM +, Colin Walters wrote: On Fri, Feb 28, 2014 at 9:36 AM, Josh Triplett j...@joshtriplett.org wrote: --- Strawman proposal, open to suggestions. ... + - Simple conditionals: C path mode user group - (tmpfiles-line) does tmpfiles-line if path has mode, user, and group: +C /usr/bin/screen 2755 root utmp - d /var/run/screen 0775 root utmp +C /usr/bin/screen 4755 root utmp - d /var/run/screen 0755 root utmp +C /usr/bin/screen 0755 root utmp - d /var/run/screen 1777 root utmp While I know I *just* posted a mail suggesting that more service state move to unit files... this feels pretty hacky to me. Are there any use cases other than screen? Games: if the game has group games and mode 2755 But yeah, it does seem like a hack. In any case, given that the Debian screen maintainer ended up accepting another solution instead (telling the admin to create an overriding /etc/tmpfiles.d file if they change the permissions, and handling upgrades via postinst), I don't feel strongly attached to this proposal if nobody sees another useful application for it. Besides, inventing a new conditional syntax seems wrong. Might work better to introduce a new unit type, foo.tmpfiles, with the full set of ConditionFoo from unit files, and then add a couple of additional ConditionFoo types based on data available by statting files. I also don't like the idea of admins configuring via chmod on stuff in /usr/bin. OSTree simply won't support that for example. I can't argue with that; I'd personally rather see screen handled via a set of packages, one per permission model, with the admin installing the one they want. Or better yet: A lot of this may come back to the discussion about screen and sessions. If for example, users could request a new headless session, then most of the screen security-related architecture would be completely unnecessary with systemd, since the per-user state could just be hooked off of the per-user runtime dir. The per-user runtime dir would stay alive because the headless session would keep the user around. I'd certainly love to see a saner implementation of screen multiuser support that doesn't require root. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] TODO: Simple conditionals in tmpfiles
--- Strawman proposal, open to suggestions. A change like this would make tmpfiles flexible enough to detect what permission configuration an admin wants to use and go along with that. In general, set a directory's permissions based on the set{u,g}id status of the binary seems common enough to want to support; tmpfiles can implement this with a simple stat and comparison. Could potentially be more configurable, by capturing the mode, user, and group of the item listed as the conditional path, and making them available as placeholders within the subitem, but that seems like overkill for the most common cases. TODO | 4 1 file changed, 4 insertions(+) diff --git a/TODO b/TODO index 6cac3e2..988f855 100644 --- a/TODO +++ b/TODO @@ -570,6 +570,10 @@ Features: * tmpfiles: - check systemd-tmpfiles for selinux context hookup for mknod(), symlink() and similar - apply x on D too (see patch from William Douglas) + - Simple conditionals: C path mode user group - (tmpfiles-line) does tmpfiles-line if path has mode, user, and group: +C /usr/bin/screen 2755 root utmp - d /var/run/screen 0775 root utmp +C /usr/bin/screen 4755 root utmp - d /var/run/screen 0755 root utmp +C /usr/bin/screen 0755 root utmp - d /var/run/screen 1777 root utmp * for services: don't set $HOME in services unless requested -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Tue, Apr 23, 2013 at 01:45:32AM +0200, Tom Gundersen wrote: On Mon, Apr 22, 2013 at 11:53 PM, Josh Triplett j...@joshtriplett.org wrote: 1) Leave only root in /etc/passwd and /etc/group. Not commenting on the overall idea, but if you are going to do something like this, at least allow the the files not to exist at all, and in this case a default entry for the root user to be assumed. Sure, seems easy enough to make that entry synthetic as part of the PAM module. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: add various journal enhancements
On Thu, Apr 18, 2013 at 12:42:38AM +0200, Kay Sievers wrote: On Thu, Apr 18, 2013 at 12:28 AM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:12:38AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:49 PM, Josh Triplett j...@joshtriplett.org wrote: + - Provide one or more FUSE filesystems: +- Emulate utmp, wtmp, btmp, lastlog; read/write, recording credentials for all writes rather than limiting permissions That sounds like overkill. We should surely externalize the creation of the files from systemd and make it optional to support legacy stuff, otherwise these files should rather be phased out, than emulated, I think. Separate, external, and optional, definitely; no sense running it if you have no tools around that read or write the format directly. But given that the glibc API (and corresponding expectations about the file format) will exist forever, it seems sensible to have a way to support that without actually having the files on the filesystem. I don't know what *forever* means here, I kind of doubt that. It's pure legacy stuff that needs that, and that works with current systemd. Most systems out there should not need these silly files at all, and the use will surely not grow in the future. Every terminal emulator, display manager, screen/tmux/etc program, or other program that needs to embed an interactive shell should log to utmp and family. The glibc API represents the standard way to do so. So either the glibc API needs to directly support logging to (and reading from) journald, or some compatibility shim like this needs to exist. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote: On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. Sorry, I lost you. I have really no idea what you are looking for. Care to start at the beginning again, I read all that again but I don't get it. :) 1) Leave only root in /etc/passwd and /etc/group. 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs. 3) When new users or groups show up, dynamically allocate new IDs for them, and record them in a separate persistent name-number mapping used by the PAM module. Keep them there as long as the .d file exists, or as long as anything on the system (file or process) uses the UID. 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse. 5) In the same daemon managing this, optionally support minting small numbers of ephemeral UIDs/GIDs for use in containers, when they don't need to map to any useful persistent privileges on the host system. Also optionally support creating new non-ephemeral UIDs/GIDs, for persistent use on the host. 6) Eventually move to a big enough ID space that reuse becomes irrelevant, and then allow users to obtain larger blocks of IDs for container use. Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2] TODO: journal enhancements
--- Resubmitting the uncontroversial bits. TODO | 2 ++ 1 file changed, 2 insertions(+) diff --git a/TODO b/TODO index 88be72d..33c24ea 100644 --- a/TODO +++ b/TODO @@ -272,6 +272,8 @@ Features: - journal: store euid in journal if it differs from uid - journal: sanely deal with entries which are larger than the individual file size, but where the components would fit - journalctl: make journalctl smarter, and actually check groups that have access to /var/log/journal before printing message about recomming group membership for journal access + - Replace utmp, wtmp, btmp, and lastlog completely with journal + - Port upower to use the journal for historical power information used in future calculations * document: - document unit_name_mangle() -- 1.8.2.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd-logind: Fix linking by reordering libraries in LDADD
libsystemd-audit needs functions from libsystemd-shared, so libsystemd-audit needs to appear first. Otherwise: CCLD systemd-logind ./.libs/libsystemd-audit.a(audit.o): In function `audit_session_from_pid': /home/josh/src/systemd/src/shared/audit.c:50: undefined reference to `detect_container' --- Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 7b4b2d8..dede567 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3461,8 +3461,8 @@ systemd_logind_CFLAGS = \ systemd_logind_LDADD = \ libsystemd-label.la \ - libsystemd-shared.la \ libsystemd-audit.la \ + libsystemd-shared.la \ libsystemd-daemon.la \ libsystemd-dbus.la \ libudev.la -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] TODO: timer unit generation
--- TODO |1 + 1 file changed, 1 insertion(+) diff --git a/TODO b/TODO index 48e5d2e..eb482d0 100644 --- a/TODO +++ b/TODO @@ -320,6 +320,7 @@ Features: o CLOCK_REALTIME makes jumps (TFD_TIMER_CANCEL_ON_SET) o DST changes - Support 2012-02~4 as syntax for specifying the fourth to last day of the month. + - unit generator for compatibility with crontab and cron.d * update the kernel's TZ (sys_tz) when DST changes -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] TODO: add various journal enhancements
--- TODO |7 +++ 1 file changed, 7 insertions(+) diff --git a/TODO b/TODO index 88be72d..48e5d2e 100644 --- a/TODO +++ b/TODO @@ -272,6 +272,13 @@ Features: - journal: store euid in journal if it differs from uid - journal: sanely deal with entries which are larger than the individual file size, but where the components would fit - journalctl: make journalctl smarter, and actually check groups that have access to /var/log/journal before printing message about recomming group membership for journal access + - Replace utmp, wtmp, btmp, and lastlog completely with journal + - Provide one or more FUSE filesystems: +- Emulate utmp, wtmp, btmp, lastlog; read/write, recording credentials for all writes rather than limiting permissions +- Provide /var/spool/crash or equivalent, exposing an index of coredumps directly +- Provide decoded text logs in /var/log + - Port upower to use the journal for historical power information used in future calculations + - Support optional database-style indexes for frequent or performance-critical queries * document: - document unit_name_mangle() -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] TODO: passwd.d, group.d
--- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. + Regularly: * look for close() vs. close_nointr() vs. close_nointr_nofail() -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: timer unit generation
On Thu, Apr 18, 2013 at 12:04:24AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: + - unit generator for compatibility with crontab and cron.d We kind of decided to port the 40-60 things that use the .d/ dirs to native units right away, and leave cron as it is, and not parse its config files from systemd. If people want cron, they should install it; new or common stuff should just not pull it in anymore. The default install should not require it. I figured this fell in the general area of wouldn't do it ourselves, but would probably take a clean patch, which seemed like a good use of TODO. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: add various journal enhancements
On Thu, Apr 18, 2013 at 12:12:38AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:49 PM, Josh Triplett j...@joshtriplett.org wrote: + - Replace utmp, wtmp, btmp, and lastlog completely with journal We should definitely add the data needed to constuct this information, if they are not already there. The tools could just use the journal directly, but there is the glibc api. Exactly; barring a compatibility library that provides the same functions as glibc, which seems hazardous, I'd like to support tools that only know how to read and write those files directly. + - Provide one or more FUSE filesystems: +- Emulate utmp, wtmp, btmp, lastlog; read/write, recording credentials for all writes rather than limiting permissions That sounds like overkill. We should surely externalize the creation of the files from systemd and make it optional to support legacy stuff, otherwise these files should rather be phased out, than emulated, I think. Separate, external, and optional, definitely; no sense running it if you have no tools around that read or write the format directly. But given that the glibc API (and corresponding expectations about the file format) will exist forever, it seems sensible to have a way to support that without actually having the files on the filesystem. +- Provide /var/spool/crash or equivalent, exposing an index of coredumps directly Coredump are really not consumed by any legacy thing that would need a file system. What do you have in mind here. Specialized apps that need that should just use the native API, not expect a file system, I think. Just an idea for how to better satisfy user expectations. Approximately zero cost, mounted on demand, gives a view into the journal. +- Provide decoded text logs in /var/log I really don't think these plain text streams make much sense today. If people want them, they should install syslog. Or some other project can do that, I'm confident we do not want that code in systemd. Maintaining a separate copy of log messages seems like overkill; I want the data stored solely in the journal. And I agree that the code doesn't belong in the journal itself; I'm suggesting that a standalone FUSE filesystem based on the journal library would prove useful for compatibility with both tools that want to consume the log format and users used to /var/log. Seems pretty trivial to write, as well. + - Port upower to use the journal for historical power information used in future calculations Yeah, that would be useful. + - Support optional database-style indexes for frequent or performance-critical queries Well, it is not a database, it's a pretty specialized format based on bisection lists. What specific thing do you have in mind? Telling the journal in advance that you'd like to make a lot of queries for PROPERTY, or for PROPERTY=value, and having it maintain an index that makes such queries faster than a linear scan and filter. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: timer unit generation
On Thu, Apr 18, 2013 at 12:15:22AM +0200, Kay Sievers wrote: On Thu, Apr 18, 2013 at 12:11 AM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:04:24AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: + - unit generator for compatibility with crontab and cron.d We kind of decided to port the 40-60 things that use the .d/ dirs to native units right away, and leave cron as it is, and not parse its config files from systemd. If people want cron, they should install it; new or common stuff should just not pull it in anymore. The default install should not require it. I figured this fell in the general area of wouldn't do it ourselves, but would probably take a clean patch, which seemed like a good use of TODO. Not really, we cannot or don't want to cover all of cron, so cron stays around anyway for the grey beards, or existing things out there. As far as I can tell, timer units already support almost everything crontabs do; the problem then just becomes a format parser and unit generator. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] TODO: uses for SO_REUSEPORT
The new socket option SO_REUSEPORT would enable some new functionality; add it to TODO. --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index f1a0bcf..f469e96 100644 --- a/TODO +++ b/TODO @@ -46,6 +46,11 @@ Fedora 19: Features: +* Support SO_REUSEPORT with socket activation: + - Let systemd maintain a pool of servers. + - Use for seamless upgrades, by running the new server before stopping the +old. + * BootLoaderSpec: drop allowing ext234 for $BOOT. Clarify that the kernel has to be in $BOOT. Clarify that the boot loader should be installed to the ESP. Define a way how an installer can figure out -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
On Wed, Mar 14, 2012 at 06:58:32PM +0100, Lennart Poettering wrote: On Wed, 07.03.12 06:34, Josh Triplett (j...@joshtriplett.org) wrote: I've attached a header file which should provide all the endianness checking you need. Just include it in place of endian.h everywhere you currently include endian.h. I stuck an all-permissive MIT license on it, for maximum possible reuse. This looks really cool! Thanks a lot for this. One comment, before we stick this into systemd: #ifndef SPARSE_ENDIAN_H #define SPARSE_ENDIAN_H #include endian.h #include stdint.h #ifdef __CHECKER__ #define __bitwise __attribute__((bitwise)) #define __force __attribute__((force)) #else #define __bitwise #define __force #endif typedef uint16_t __bitwise le16; typedef uint16_t __bitwise be16; typedef uint32_t __bitwise le32; typedef uint32_t __bitwise be32; typedef uint64_t __bitwise le64; typedef uint64_t __bitwise be64; Can we add a suffix _t here? I much prefer le16_t over le16, since this is a type. Sure, feel free. I used the unsuffixed names to match the kernel's type names and the names used in the conversion functions, but the endianness checking will obviously work with whatever names you prefer. :) The following sed line will give you the names you want: sed -i 's/\[bl]e\(16\|32\|64\)\/_t/g' sparse-endian.h (and also, emacs' recognizes this and highlights it differently ;-)) I just checked with emacs -q, and at least on my system emacs seems to correctly identify and highlight all six of those names as types by default, in all the contexts I can think of where a type can appear. Take a look at https://www.gnu.org/software/emacs/manual/html_node/ccmode/Font-Locking-Preliminaries.html ; you may want to make sure you have your font-lock level set sufficiently high. Thanks! No problem; I look forward to seeing what endianness bugs you can squash with this. :) - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Move /tmp and /var/tmp to a separate tmpfiles.d file to ease overrides via /etc
On Wed, Aug 24, 2011 at 08:39:38PM +0200, Lennart Poettering wrote: On Sat, 06.08.11 15:48, Josh Triplett (j...@joshtriplett.org) wrote: Many people prefer to avoid clearing /tmp and /var/tmp, and distributions often have explicit settings for how often to clear them if at all. Overriding those with systemd currently requires overriding all of /usr/lib/tmpfiles.d/systemd.conf via /etc/tmpfiles.d/systemd.conf, copying across all the other entries, and updating that override when systemd.conf changes. Move the /tmp and /var/tmp entries from systemd.conf to a separate tmp.conf, making them easier to override without affecting the rest of systemd.conf. Applied. Thanks! Excellent, thank you! - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Move /tmp and /var/tmp to a separate tmpfiles.d file to ease overrides via /etc
On Mon, Aug 15, 2011 at 04:25:58PM +0200, jean-michel.poll...@laposte.net wrote: Regarding this issue, there's also the fact that the default files do not clear /tmp as they are. Is it OK to default the type to D instead of d for /tmp in the systemd.conf file, so that it is cleared on boot? Files in /tmp get cleared when older than 10 days; that seems like a fine default. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Move /tmp and /var/tmp to a separate tmpfiles.d file to ease overrides via /etc
Many people prefer to avoid clearing /tmp and /var/tmp, and distributions often have explicit settings for how often to clear them if at all. Overriding those with systemd currently requires overriding all of /usr/lib/tmpfiles.d/systemd.conf via /etc/tmpfiles.d/systemd.conf, copying across all the other entries, and updating that override when systemd.conf changes. Move the /tmp and /var/tmp entries from systemd.conf to a separate tmp.conf, making them easier to override without affecting the rest of systemd.conf. --- This change will allow me to create a personal package which ships /etc/tmpfiles.d/tmp.conf, without having to include the remainder of systemd.conf and update the package every time systemd.conf changes. Makefile.am |1 + tmpfiles.d/systemd.conf |3 --- tmpfiles.d/tmp.conf | 12 3 files changed, 13 insertions(+), 3 deletions(-) create mode 100644 tmpfiles.d/tmp.conf diff --git a/Makefile.am b/Makefile.am index b9c8074..2dc3579 100644 --- a/Makefile.am +++ b/Makefile.am @@ -285,6 +285,7 @@ dist_bashcompletion_DATA = \ dist_tmpfiles_DATA = \ tmpfiles.d/systemd.conf \ + tmpfiles.d/tmp.conf \ tmpfiles.d/x11.conf if HAVE_SYSV_COMPAT diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf index 7d4b356..be29c06 100644 --- a/tmpfiles.d/systemd.conf +++ b/tmpfiles.d/systemd.conf @@ -13,9 +13,6 @@ F /run/utmp 0664 root utmp - f /var/log/wtmp 0664 root utmp - f /var/log/btmp 0600 root utmp - -d /tmp 1777 root root 10d -d /var/tmp 1777 root root 30d - d /var/cache/man - - - 30d r /forcefsck diff --git a/tmpfiles.d/tmp.conf b/tmpfiles.d/tmp.conf new file mode 100644 index 000..8915b82 --- /dev/null +++ b/tmpfiles.d/tmp.conf @@ -0,0 +1,12 @@ +# 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. + +# See tmpfiles.d(5) for details + +# Clear tmp directories separately, to make them easier to override +d /tmp 1777 root root 10d +d /var/tmp 1777 root root 30d -- 1.7.5.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Remove X11 lock files for displays :10 and higher too
--- Using .X[0-9]*-lock seems safe to me, but if you prefer I can write separate lines for [0-9], [0-9][0-9], and [0-9][0-9][0-9]. Now if only tmpfiles.d could do regexes or extglob rather than just shell-style globs. :) tmpfiles.d/x11.conf |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tmpfiles.d/x11.conf b/tmpfiles.d/x11.conf index 5072b58..7f81af6 100644 --- a/tmpfiles.d/x11.conf +++ b/tmpfiles.d/x11.conf @@ -15,4 +15,4 @@ d /tmp/.font-unix 1777 root root 10d d /tmp/.Test-unix 1777 root root 10d # Unlink the X11 lock files -r /tmp/.X[0-9]-lock +r /tmp/.X[0-9]*-lock -- 1.7.5.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] What makes systemd-nspawn not suitable for secure container setups?
The systemd-nspawn manpage lists the various mechanisms used to isolate the container, and then says Note that even though these security precautions are taken systemd-nspawn is not suitable for secure container setups. Many of the security features may be circumvented and are hence primarily useful to avoid accidental changes to the host system from the container. How can a process in a systemd-nspawn container circumvent the container setup? What additional steps would systemd-nspawn need to take to provide a secure container setup? - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] What makes systemd-nspawn not suitable for secure container setups?
The systemd-nspawn manpage lists the various mechanisms used to isolate the container, and then says Note that even though these security precautions are taken systemd-nspawn is not suitable for secure container setups. Many of the security features may be circumvented and are hence primarily useful to avoid accidental changes to the host system from the container. How can a process in a systemd-nspawn container circumvent the container setup? What additional steps would systemd-nspawn need to take to provide a secure container setup? - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What makes systemd-nspawn not suitable for secure container setups?
On Sat, Apr 23, 2011 at 11:28:58AM +0800, microcai wrote: 于 2011年04月23日 10:55, Josh Triplett 写道: The systemd-nspawn manpage lists the various mechanisms used to isolate the container, and then says Note that even though these security precautions are taken systemd-nspawn is not suitable for secure container setups. Many of the security features may be circumvented and are hence primarily useful to avoid accidental changes to the host system from the container. How can a process in a systemd-nspawn container circumvent the container remount /proc and /sys Ah, good point. So, root inside the container can trivially circumvent the container that way. Any way to prevent that with current kernel support, or would fixing this require additional kernel changes to lock down other /proc and /sys mounts? That particular problem only applies if running code within the container as root. How about if running code as an unprivileged user? With that addition, does systemd-nspawn provide a secure container (modulo local privilege escalation vulnerabilities)? Thanks, Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel