Re: [systemd-devel] [PATCH] sd-dhcp-client: prevent timer related memory leaks
> -Original Message- > From: Lennart Poettering [mailto:lenn...@poettering.net] > Sent: den 21 februari 2014 03:22 > To: Umut Tezduyar Lindskog > Cc: systemd-devel@lists.freedesktop.org; Umut Tezduyar Lindskog > Subject: Re: [systemd-devel] [PATCH] sd-dhcp-client: prevent timer related > memory leaks > > On Thu, 20.02.14 21:04, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) > wrote: > > Tom commited this. Thanks! > > Tom, please always do a quick reply on the ML so that it is easy to see what > is > commited and what is not! > > Thanks! Hi, actually he did but maybe there is an oversight. I kept track of it too :) Umut > > > --- > > src/libsystemd-dhcp/sd-dhcp-client.c |4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/src/libsystemd-dhcp/sd-dhcp-client.c > > b/src/libsystemd-dhcp/sd-dhcp-client.c > > index ec2b53f..53abe22 100644 > > --- a/src/libsystemd-dhcp/sd-dhcp-client.c > > +++ b/src/libsystemd-dhcp/sd-dhcp-client.c > > @@ -392,6 +392,8 @@ static int client_timeout_resend(sd_event_source > > *s, uint64_t usec, > > > > next_timeout += (random_u32() & 0x1f); > > > > +client->timeout_resend = > > + sd_event_source_unref(client->timeout_resend); > > + > > r = sd_event_add_monotonic(client->event, > > &client->timeout_resend, > > next_timeout, @@ -477,6 +479,8 > > @@ static int client_initialize_events(sd_dhcp_client *client, > > if (r < 0) > > goto error; > > > > +client->timeout_resend = > > + sd_event_source_unref(client->timeout_resend); > > + > > r = sd_event_add_monotonic(client->event, > > &client->timeout_resend, > > usec, 0, > > > Lennart > > -- > Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd on by default?
> -Original Message- > From: systemd-devel-boun...@lists.freedesktop.org [mailto:systemd- > devel-boun...@lists.freedesktop.org] On Behalf Of Zbigniew Jedrzejewski- > Szmek > Sent: den 21 februari 2014 04:42 > To: Jason A. Donenfeld > Cc: systemd Mailing List > Subject: Re: [systemd-devel] systemd-networkd on by default? > > On Fri, Feb 21, 2014 at 04:00:10AM +0100, Jason A. Donenfeld wrote: > > Hi folks, > > > > systemd-networkd seems to get started by default in 209. Why is this? > > What if I don't want to use it to manage my networks? Why does it have > > to be on by default? > I think the reasoning was that it doesn't do anything by default (when there > are no configuration files), so it is safe to enable. Maybe it should be made > conditional on the existence of configuration files. > > Zbyszek It can also be disabled by configure flag --disable-networkd. Thanks, Umut > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add setns() functions if not in the C library.
Compilation works okay here. And "make check" said "PASS: test-namespace". > The change I made is to complain if __NR_setns is not defined. The approach with an error message (at runtime) was taken from iproute2. I used that because for many (desktop) users namespace support isn't really needed. So if the libc would really not provide it, ... who cares. Then just the namespace related units wouldn't work, and they are not central to system bringup. I didn't knew the syscall numbers differs between architectures. It never occured to me that this could be a sane design :-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd on by default?
On Fri, Feb 21, 2014 at 04:00:10AM +0100, Jason A. Donenfeld wrote: > Hi folks, > > systemd-networkd seems to get started by default in 209. Why is this? > What if I don't want to use it to manage my networks? Why does it have > to be on by default? I think the reasoning was that it doesn't do anything by default (when there are no configuration files), so it is safe to enable. Maybe it should be made conditional on the existence of configuration files. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
systemd-network.service should not be started unless the administrator runs "systemctl enable systemd-network.service", as it's entirely unessential and most distributions use their own network management daemons instead. If some distributions or users choose to use systemd's built in networking, then it is simple enough to enable. But by default, it doesn't make sense to waste resources running this when no networks are configured with it. --- Makefile.am | 3 --- units/systemd-networkd.service.in | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile.am b/Makefile.am index c71367d..0e4ce72 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3921,9 +3921,6 @@ systemd_networkd_LDADD = \ nodist_systemunit_DATA += \ units/systemd-networkd.service -MULTI_USER_TARGET_WANTS += \ - systemd-networkd.service - test_network_SOURCES = \ src/network/test-network.c \ src/network/networkd.h \ diff --git a/units/systemd-networkd.service.in b/units/systemd-networkd.service.in index 835c07d..ca40691 100644 --- a/units/systemd-networkd.service.in +++ b/units/systemd-networkd.service.in @@ -20,3 +20,6 @@ Restart=always RestartSec=0 ExecStart=@rootlibexecdir@/systemd-networkd WatchdogSec=1min + +[Install] +WantedBy=multi-user.target -- 1.8.5.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd on by default?
Hi folks, systemd-networkd seems to get started by default in 209. Why is this? What if I don't want to use it to manage my networks? Why does it have to be on by default? Jason ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] replace tabs with spaces in some files
On Thu, 20.02.14 18:09, Jason St. John (jstj...@purdue.edu) wrote: Applied! Thanks! > I also noticed that kdbus.h uses tabs exclusively. Is this something that > should be fixed too? Greg's right, this should not be fixed. kdbus.h and a couple of drop-in headers we copied from other projects should always stay in the original state so that we can easily sync and diff them from/to upstream. Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add AppArmor profile switching
On Thu, 20.02.14 16:19, m...@zarb.org (m...@zarb.org) wrote: > From: Michael Scherer > > This permit to switch to a specific apparmor profile when starting a daemon. > This > will result in a non operation if apparmor is disabled. > It also add a new build requirement on libapparmor for using this > feature. Applied! I made some changes though, there were some missing bits to make sure the config hookup works correctly. I don't have any apparmor available though. Could you check if everything works correctly? I figure the only missing bit to get apparmor up to the same level of support in systemd as SELinux, SMACK and IMA have would be policy uploading during early boot. Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
On Thu, 20.02.14 23:44, Colin Walters (walt...@verbum.org) wrote: > On Thu, Feb 20, 2014 at 4:21 PM, Colin Walters > wrote: > > > >I'm testing this suggested patch now. > > > I tweaked the suggestion a bit because the selinux_path() API call > made the most sense inside selinux-setup.c. Attached patch works > for me. It's actually even easier than this patch, as in_initrd() is a normal exported function, we can call it directly from selinux_setup(). I have made that change to your patch and commited it. Please test! Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unmentioned 209 change: 80-net-name-slot.rules is gone
Hey guys, This commit caught me by surprise: http://git.zx2c4.com/systemd/commit/?id=daeb71a36a98834664e4d95773a3629b746f4db8 It wasn't in the NEWS or the mailing list post for 209, so when updating I encountered a bit of unexpected behavior. I see that I can disable persistent names using net.ifnames=0 in my kernel command line. Still not certain what the equivalent of the udev rule override is, though. Jason ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] socket-proxyd: resolve addrinfo using sd-resolve
On Thu, 20.02.14 21:11, Daniel Buch (boogiewasth...@gmail.com) wrote:
>
> log_debug("Looking up address info for %s:%s", node,
> service);
> -r = getaddrinfo(node, service, &hints, &result);
> -if (r != 0) {
> +r = sd_resolve_getaddrinfo(resolve, &q, node, service,
> &hints);
> +if (r < 0)
> +log_error("Error: %s %d\n", gai_strerror(r), r);
> +
> +while (!sd_resolve_is_done(q)) {
> +r = sd_resolve_wait(resolve, (uint64_t) -1);
> +if (r < 0) {
> +log_error("Error: %s\n", strerror(-r));
> +assert_not_reached("sd_resolve_wait()
> failed");
> +}
> +}
> +
> +r = sd_resolve_getaddrinfo_done(q, &result);
> +if (r < 0) {
> log_error("Failed to resolve host %s:%s: %s", node,
> service, gai_strerror(r));
> return -EHOSTUNREACH;
> }
Yupp, as David already pointed out, this takes the async API and makes
it sync again...
I figure before we can implement this part in the socket proxy we need
to enhance sd-resolve to provide hooks into the event loop. And that
probably means we also need to teach it callbacks...
So I figure this is a bit more difficult to do...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: prevent timer related memory leaks
On Thu, 20.02.14 21:04, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: Tom commited this. Thanks! Tom, please always do a quick reply on the ML so that it is easy to see what is commited and what is not! Thanks! > --- > src/libsystemd-dhcp/sd-dhcp-client.c |4 > 1 file changed, 4 insertions(+) > > diff --git a/src/libsystemd-dhcp/sd-dhcp-client.c > b/src/libsystemd-dhcp/sd-dhcp-client.c > index ec2b53f..53abe22 100644 > --- a/src/libsystemd-dhcp/sd-dhcp-client.c > +++ b/src/libsystemd-dhcp/sd-dhcp-client.c > @@ -392,6 +392,8 @@ static int client_timeout_resend(sd_event_source *s, > uint64_t usec, > > next_timeout += (random_u32() & 0x1f); > > +client->timeout_resend = > sd_event_source_unref(client->timeout_resend); > + > r = sd_event_add_monotonic(client->event, > &client->timeout_resend, > next_timeout, > @@ -477,6 +479,8 @@ static int client_initialize_events(sd_dhcp_client > *client, > if (r < 0) > goto error; > > +client->timeout_resend = > sd_event_source_unref(client->timeout_resend); > + > r = sd_event_add_monotonic(client->event, > &client->timeout_resend, > usec, 0, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Build warnings for ARM due to -Wcast-align
On Thu, 20.02.14 22:26, Thomas H.P. Andersen (pho...@gmail.com) wrote: > > On Thu, Feb 20, 2014 at 5:03 PM, Daniel Mack wrote: > > Hi, > > > > When cross-compiling the current git HEAD for ARM using gcc 4.8.2, I see > > ~160 warnings similar to this one: > > > > src/core/unit.c: In function 'unit_get_exec_runtime': > > src/core/unit.c:2851:17: warning: cast increases required alignment of > > target type [-Wcast-align] > > return *(ExecRuntime**) ((uint8_t*) u + offset); > > ^ > > > > The full build log is here: > > > > http://paste.fedoraproject.org/78944/92912005 > > > > Unaligned memory access is indeed unsupported by some older instruction > > cores. The kernel can fix up in situations where such unaligned access > > occurs, but that's of course expensive and slow. > > > > However, systemd does not actually do unaligned memory access at runtime > > (at least I haven't seen any when booting up PXA3xx hardware). The > > warning is simply about the type of pointer arithmetic that casts to and > > from uint8_t*. > > > > And because it's practically impossible to fix the things the compiler > > complains about here anyway, I propose removing -Wcast-align from the > > CFLAGS in configure.ac. > > > > Any opinions? > > Clang also caught those. I had to add -Wno-cast-align in the > autogen-shortcut to keep the noise down. It would be nice not to have > to do that of course. I have removed the switch now. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] FIx compilation of nspawn when seccomp is not enabled
On Thu, 20.02.14 16:07, m...@zarb.org (m...@zarb.org) wrote: Thanks! Applied! > From: Michael Scherer > > --- > Makefile.am | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/Makefile.am b/Makefile.am > index 08b94d7..e4ff7de 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -1868,9 +1868,13 @@ systemd_nspawn_LDADD = \ > libsystemd-capability.la \ > libsystemd-internal.la \ > libudev-internal.la \ > - libsystemd-shared.la \ > + libsystemd-shared.la > + > +if HAVE_SECCOMP > +systemd_nspawn_LDADD += \ > libsystemd-seccomp.la \ > $(SECCOMP_LIBS) > +endif > > # > -- > systemd_run_SOURCES = \ Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add setns() functions if not in the C library.
On Thu, 20.02.14 14:39, Holger Schurig (holgerschu...@gmail.com) wrote:
> Debian Stable is still using glibc 2.13, which doesn't provide the setns().
> So we detect this and provide a tiny wrapper that issues the setns syscall
> towards the kernel.
I modified your patch and commited it. The change I made is to complain
if __NR_setns is not defined. I also added the right definitions for the
two x86 archs in. Please test if things work now for you.
> ---
> configure.ac |3 +++
> src/shared/missing.h | 13 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 05ee098..40162ba 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -250,6 +250,9 @@ AC_CHECK_DECLS([gettid, pivot_root, name_to_handle_at],
> [], [], [[#include m4_pattern_forbid([^_?PKG_[A-Z_]+$],[*** pkg.m4 missing, please install
> pkg-config])
>
> #
> --
> +AC_CHECK_FUNCS([setns])
> +
> +#
> --
> have_dbus=no
> AC_ARG_ENABLE(dbus, AS_HELP_STRING([--disable-dbus], [disable usage of
> dbus-1 in tests]))
> AS_IF([test "x$enable_dbus" != "xno"], [
> diff --git a/src/shared/missing.h b/src/shared/missing.h
> index 2661285..ea87053 100644
> --- a/src/shared/missing.h
> +++ b/src/shared/missing.h
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -352,4 +353,16 @@ static inline int name_to_handle_at(int fd, const char
> *name, struct file_handle
> #define O_TMPFILE (__O_TMPFILE | O_DIRECTORY)
> #endif
>
> +#ifndef HAVE_SETNS
> +static inline int setns(int fd, int nstype)
> +{
> +#ifdef __NR_setns
> +return syscall(__NR_setns, fd, nstype);
> +#else
> +errno = ENOSYS;
> +return -1;
> +#endif
> +}
> +#endif
> +
> #endif
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
On Thu, Feb 20, 2014 at 4:21 PM, Colin Walters
wrote:
I'm testing this suggested patch now.
I tweaked the suggestion a bit because the selinux_path() API call made
the most sense inside selinux-setup.c. Attached patch works for me.
>From ae5f54b4d34320528db8fd1bb24ab7479d081594 Mon Sep 17 00:00:00 2001
From: Colin Walters
Date: Thu, 20 Feb 2014 10:15:10 -0500
Subject: [PATCH] selinux: Don't attempt to load policy in initramfs if it
doesn't exist
Currently on at least Fedora, SELinux policy does not come in the
initramfs. systemd will attempt to load *both* in the initramfs and
in the real root.
Now, the selinux_init_load_policy() API has a regular error return
value, as well as an "enforcing" boolean. To determine enforcing
state, it looks for /etc/selinux/config as well as the presence of
"enforcing=" on the kernel command line.
Ordinarily, neither of those exist in the initramfs, so it will return
"unknown" for enforcing, and systemd will simply ignore the failure to
load policy.
Then later after we switch to the real root, we have the config file,
and all will work properly.
Except...this all blows up if someone explicitly specifies enforcing=1
on the kernel command line. Then systemd will fail to load the
nonexistent policy in the initramfs and freeze.
This patch tweaks the logic so we attempt to load policy from the
initramfs only if we see it exists. We always attempt to load from
the real root - but selinux_setup() is a noop if policy is already
loaded, so the case of "policy successfully loaded in initramfs, not
in the real root" will work.
Lots-of-very-painful-debugging-by: Colin Walters
---
src/core/main.c | 2 +-
src/core/selinux-setup.c | 9 -
src/core/selinux-setup.h | 2 +-
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/core/main.c b/src/core/main.c
index 58c3a9e..49f237a 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1296,7 +1296,7 @@ int main(int argc, char *argv[]) {
if (!skip_setup) {
mount_setup_early();
-if (selinux_setup(&loaded_policy) < 0)
+if (selinux_setup(in_initrd(), &loaded_policy) < 0)
goto finish;
if (ima_setup() < 0)
goto finish;
diff --git a/src/core/selinux-setup.c b/src/core/selinux-setup.c
index 7a32ed5..ee0ac32 100644
--- a/src/core/selinux-setup.c
+++ b/src/core/selinux-setup.c
@@ -43,7 +43,7 @@ static int null_log(int type, const char *fmt, ...) {
}
#endif
-int selinux_setup(bool *loaded_policy) {
+int selinux_setup(bool in_initrd, bool *loaded_policy) {
#ifdef HAVE_SELINUX
int enforce = 0;
@@ -54,6 +54,13 @@ int selinux_setup(bool *loaded_policy) {
assert(loaded_policy);
+ /* Don't load policy in the initrd if we don't appear to have
+* it. For the real root, we check below if we've already
+* loaded policy, and return gracefully.
+*/
+ if (in_initrd && access(selinux_path(), F_OK) == -1)
+ return 0;
+
/* Turn off all of SELinux' own logging, we want to do that */
cb.func_log = null_log;
selinux_set_callback(SELINUX_CB_LOG, cb);
diff --git a/src/core/selinux-setup.h b/src/core/selinux-setup.h
index 39e2bc2..9291144 100644
--- a/src/core/selinux-setup.h
+++ b/src/core/selinux-setup.h
@@ -23,4 +23,4 @@
#include
-int selinux_setup(bool *loaded_policy);
+int selinux_setup(bool in_initrd, bool *loaded_policy);
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting CUPS very late on a desktop and non-server system
This might be of interest to you: http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-February/001433.html So, the cups maintainer is already looking into this. It has to be said CUPS is not the most trivial wrt proper systemd support. 2014-02-20 23:18 GMT+01:00 Paul Menzel : > Dear systemd folks, > > > after Debian's CTTE chose systemd as the default init system for the > next Debian release, I installed it on one of the systems. > > Looking at the output `systemd-analyze plot`, I noticed that CUPS takes > 700 ms to start and as this is a desktop system where not a lot is > printed and when, then only after the user has logged in, I wonder how > that can be dealt with systemd. Like starting it only after user login? > Or is that something which is not nicely doable because CUPS runs as a > system daemon? > > > Thanks, > > Paul > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] replace tabs with spaces in some files
On Thu, Feb 20, 2014 at 06:09:27PM -0500, Jason St. John wrote: > Files: > * hwdb/60-keyboard.hwdb > * shell-completion/zsh/_systemd-coredumpctl > * src/test/test-helper.h > --- > I also noticed that kdbus.h uses tabs exclusively. Is this something that > should be fixed too? kdbus.h will end up in the kernel source tree, so it needs to keep tabs to align with that project's coding convention. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker, Supervisor and systemd
On Thu, Feb 20, 2014 at 2:25 PM, Paul Menzel wrote: > Or is there a reason why systemd should not be used for that? Distro portability, but that's rapidly dying as a reason. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] socket-proxyd: resolve addrinfo using sd-resolve
It's not ridiculous, but it's also no better. This patch still blocks the main event loop during each lookup. Proper integration of non-blocking lookup would involve using sd_resolve_get_fd() to integrate with the main event loop. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] replace tabs with spaces in some files
Files:
* hwdb/60-keyboard.hwdb
* shell-completion/zsh/_systemd-coredumpctl
* src/test/test-helper.h
---
I also noticed that kdbus.h uses tabs exclusively. Is this something that
should be fixed too?
hwdb/60-keyboard.hwdb | 4 ++--
shell-completion/zsh/_systemd-coredumpctl | 4 ++--
src/test/test-helper.h| 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/hwdb/60-keyboard.hwdb b/hwdb/60-keyboard.hwdb
index 9eb460c..edfa842 100644
--- a/hwdb/60-keyboard.hwdb
+++ b/hwdb/60-keyboard.hwdb
@@ -76,7 +76,7 @@ keyboard:dmi:bvn*:bvr*:bd*:svneMachines:pneMachines*E725:pvr*
# Acer platform kernel driver
keyboard:name:Acer WMI hotkeys:dmi:bvn*:bvr*:bd*:svn*:pnAcer*:pvr*
- KEYBOARD_KEY_82=f21 # Touchpad toggle
+ KEYBOARD_KEY_82=f21# Touchpad toggle
# Aspire models
keyboard:dmi:bvn*:bvr*:bd*:svnAcer*:pnAspire*:pvr*
@@ -138,7 +138,7 @@ keyboard:dmi:bvn*:bvr*:bd*:svnASUS:pn*
KEYBOARD_KEY_ef=mute
keyboard:name:Asus WMI hotkeys:dmi:bvn*:bvr*:bd*:svnASUS*:pn*:pvr*
- KEYBOARD_KEY_6b=f21 # Touchpad Toggle
+ KEYBOARD_KEY_6b=f21# Touchpad Toggle
###
# BenQ
diff --git a/shell-completion/zsh/_systemd-coredumpctl
b/shell-completion/zsh/_systemd-coredumpctl
index 159e8ee..94b1e92 100644
--- a/shell-completion/zsh/_systemd-coredumpctl
+++ b/shell-completion/zsh/_systemd-coredumpctl
@@ -14,8 +14,8 @@ _systemd-coredumpctl_command(){
local -a _dumps
cmd="${${_systemd_coredumpctl_cmds[(r)$words[1]:*]%%:*}}"
if (( $#cmd )); then
- # user can set zstyle
':completion:*:*:systemd-coredumpctl:*' sort no for coredumps to be ordered by
date, otherwise they get ordered by pid
- _dumps=( "${(foa)$(systemd-coredumpctl list | awk
'BEGIN{OFS=":"} /^\s/ {sub(/[[ \t]+/, ""); print $5,$0}' 2>/dev/null)}" )
+# user can set zstyle ':completion:*:*:systemd-coredumpctl:*' sort
no for coredumps to be ordered by date, otherwise they get ordered by pid
+_dumps=( "${(foa)$(systemd-coredumpctl list | awk 'BEGIN{OFS=":"}
/^\s/ {sub(/[[ \t]+/, ""); print $5,$0}' 2>/dev/null)}" )
if [[ -n "$_dumps" ]]; then
_describe -t pids 'coredumps' _dumps
else
diff --git a/src/test/test-helper.h b/src/test/test-helper.h
index 92864ed..f75dd33 100644
--- a/src/test/test-helper.h
+++ b/src/test/test-helper.h
@@ -24,8 +24,8 @@
#include "sd-daemon.h"
#define TEST_REQ_RUNNING_SYSTEMD(x) \
- if (sd_booted() > 0) { \
- x; \
+if (sd_booted() > 0) { \
+x; \
} else {\
printf("systemd not booted skipping '%s'\n", #x); \
}
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting CUPS very late on a desktop and non-server system
Le jeudi 20 février 2014 à 23:18 +0100, Paul Menzel a écrit : > Dear systemd folks, > > > after Debian’s CTTE chose systemd as the default init system for the > next Debian release, I installed it on one of the systems. > > Looking at the output `systemd-analyze plot`, I noticed that CUPS takes > 700 ms to start and as this is a desktop system where not a lot is > printed and when, then only after the user has logged in, I wonder how > that can be dealt with systemd. Like starting it only after user login? > Or is that something which is not nicely doable because CUPS runs as a > system daemon? You can start it on demand, using the activation socket system. See http://0pointer.de/blog/projects/socket-activation2.html ( since that date back to 2011, there is likely everything already patched upstream in a stable release ) -- Michael Scherer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Starting CUPS very late on a desktop and non-server system
Dear systemd folks, after Debian’s CTTE chose systemd as the default init system for the next Debian release, I installed it on one of the systems. Looking at the output `systemd-analyze plot`, I noticed that CUPS takes 700 ms to start and as this is a desktop system where not a lot is printed and when, then only after the user has logged in, I wonder how that can be dealt with systemd. Like starting it only after user login? Or is that something which is not nicely doable because CUPS runs as a system daemon? Thanks, Paul signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Docker, Supervisor and systemd
Dear systemd folks, Docker, “an open-source project to easily create lightweight, portable, self-sufficient containers from any application”, [1] mostly recommends to use Supervisor [2] to control the processes to be run in the container, like starting and restarting them and logging the output. Actually all things systemd also does to my knowledge. Supervisor also needs a configuration file for each process, which it should start. Has somebody experiences to use systemd for that? Or is there a reason why systemd should not be used for that? Thanks, Paul [1] https://www.docker.io/ [2] http://supervisord.org/ signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
On Thu, Feb 20, 2014 at 4:10 PM, Eric Paris wrote: I think the idea was if we are not in the initrd - try to load policy if we are in the initrd and we find selinux_path() - try to load policy Thus embeded/thin who put everything inside the initrd will work (and the kernel enforce=1 will mean what is should) And where we don't put anything inside the initrd will still be correct since we'll try to load no matter what in the real root I guess then as long as we don't attempt to load policy again if we already have done so in the initrd - and yes, systemd already has logic of this form inside selinux_setup(). I'm testing this suggested patch now. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Build warnings for ARM due to -Wcast-align
On Thu, Feb 20, 2014 at 5:03 PM, Daniel Mack wrote: > Hi, > > When cross-compiling the current git HEAD for ARM using gcc 4.8.2, I see > ~160 warnings similar to this one: > > src/core/unit.c: In function 'unit_get_exec_runtime': > src/core/unit.c:2851:17: warning: cast increases required alignment of > target type [-Wcast-align] > return *(ExecRuntime**) ((uint8_t*) u + offset); > ^ > > The full build log is here: > > http://paste.fedoraproject.org/78944/92912005 > > Unaligned memory access is indeed unsupported by some older instruction > cores. The kernel can fix up in situations where such unaligned access > occurs, but that's of course expensive and slow. > > However, systemd does not actually do unaligned memory access at runtime > (at least I haven't seen any when booting up PXA3xx hardware). The > warning is simply about the type of pointer arithmetic that casts to and > from uint8_t*. > > And because it's practically impossible to fix the things the compiler > complains about here anyway, I propose removing -Wcast-align from the > CFLAGS in configure.ac. > > Any opinions? Clang also caught those. I had to add -Wno-cast-align in the autogen-shortcut to keep the noise down. It would be nice not to have to do that of course. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
I think the idea was if we are not in the initrd - try to load policy if we are in the initrd and we find selinux_path() - try to load policy Thus embeded/thin who put everything inside the initrd will work (and the kernel enforce=1 will mean what is should) And where we don't put anything inside the initrd will still be correct since we'll try to load no matter what in the real root On Thu, Feb 20, 2014 at 3:52 PM, Colin Walters wrote: > On Thu, Feb 20, 2014 at 2:45 PM, Daniel J Walsh wrote: > > You mean "!in_initrd() || access(selinux_path(), F_OK) >= 0"? > > > I don't think so - that would mean we would silently continue if > enforcing=1, but we happen to not find a policy on disk. Right? > > I think my patch is better than this - systemd will attempt to load policy > from *only* the real root (not the initramfs), using the exact same logic as > is in libselinux currently. > > For example, it would allow explicitly specifying enforcing=1 on the kernel > command line, and that would continue to cause an explicit failure if policy > is not found. > > > > ___ > Selinux mailing list > seli...@tycho.nsa.gov > To unsubscribe, send email to selinux-le...@tycho.nsa.gov. > To get help, send an email containing "help" to > selinux-requ...@tycho.nsa.gov. > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
On Thu, Feb 20, 2014 at 2:45 PM, Daniel J Walsh wrote: You mean "!in_initrd() || access(selinux_path(), F_OK) >= 0"? I don't think so - that would mean we would silently continue if enforcing=1, but we happen to not find a policy on disk. Right? I think my patch is better than this - systemd will attempt to load policy from *only* the real root (not the initramfs), using the exact same logic as is in libselinux currently. For example, it would allow explicitly specifying enforcing=1 on the kernel command line, and that would continue to cause an explicit failure if policy is not found. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC] socket-proxyd: resolve addrinfo using sd-resolve
Hi,
Hope this is not completly ridiculous?
I havnt tested this since im not entirely sure how to do it.
So tips and comments regarding that are very welcome, im tempt to research
further and maybe eventually provide a test for socket-proxy.
Best regards.
---
Makefile.am | 4 +++-
TODO | 2 --
src/socket-proxy/socket-proxyd.c | 29 +++--
3 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 03a65bf..a50a032 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -195,6 +195,7 @@ AM_CPPFLAGS = \
-I $(top_builddir)/src/udev \
-I $(top_srcdir)/src/libsystemd/sd-bus \
-I $(top_srcdir)/src/libsystemd/sd-event \
+ -I $(top_srcdir)/src/libsystemd/sd-resolve \
-I $(top_srcdir)/src/libsystemd/sd-rtnl \
$(OUR_CPPFLAGS)
@@ -3315,7 +3316,8 @@ systemd_socket_proxyd_LDADD = \
libsystemd-logs.la \
libsystemd-internal.la \
libsystemd-journal-internal.la \
- libsystemd-shared.la
+ libsystemd-shared.la \
+ -lresolv
#
--
if ENABLE_COREDUMP
diff --git a/TODO b/TODO
index 0ae1427..c6ccc8c 100644
--- a/TODO
+++ b/TODO
@@ -113,8 +113,6 @@ Features:
* Automatically configure swap partition to use for hibernation by looking for
largest swap partition on the root disk?
-* socket-proxyd: Use sd-resolve to resolve the server address
-
* rfkill,backlight: we probably should run the load tools inside of the udev
rules so that the state is properly initialized by the time other software sees
it
* move config_parse_path_strv() out of conf-parser.c
diff --git a/src/socket-proxy/socket-proxyd.c b/src/socket-proxy/socket-proxyd.c
index a42e5ae..cd9b95b 100644
--- a/src/socket-proxy/socket-proxyd.c
+++ b/src/socket-proxy/socket-proxyd.c
@@ -40,13 +40,12 @@
#include "build.h"
#include "set.h"
#include "path-util.h"
+#include "sd-resolve.h"
+#include "resolve-util.h"
#define BUFFER_SIZE (256 * 1024)
#define CONNECTIONS_MAX 256
-#define _cleanup_freeaddrinfo_ _cleanup_(freeaddrinfop)
-DEFINE_TRIVIAL_CLEANUP_FUNC(struct addrinfo *, freeaddrinfo);
-
typedef struct Context {
Set *listen;
Set *connections;
@@ -125,7 +124,9 @@ static int get_remote_sockaddr(union sockaddr_union *sa,
socklen_t *salen) {
*salen = offsetof(union sockaddr_union, un.sun_path) + 1 +
strlen(sa->un.sun_path + 1);
} else {
-_cleanup_freeaddrinfo_ struct addrinfo *result = NULL;
+_cleanup_resolve_unref_ sd_resolve *resolve = NULL;
+_cleanup_resolve_addrinfo_free_ struct addrinfo *result = NULL;
+sd_resolve_query *q = NULL;
const char *node, *service;
struct addrinfo hints = {
@@ -134,6 +135,10 @@ static int get_remote_sockaddr(union sockaddr_union *sa,
socklen_t *salen) {
.ai_flags = AI_ADDRCONFIG
};
+r = sd_resolve_new(&resolve);
+if (r < 0)
+return -ENOMEM;
+
service = strrchr(arg_remote_host, ':');
if (service) {
node = strndupa(arg_remote_host, service -
arg_remote_host);
@@ -144,8 +149,20 @@ static int get_remote_sockaddr(union sockaddr_union *sa,
socklen_t *salen) {
}
log_debug("Looking up address info for %s:%s", node, service);
-r = getaddrinfo(node, service, &hints, &result);
-if (r != 0) {
+r = sd_resolve_getaddrinfo(resolve, &q, node, service, &hints);
+if (r < 0)
+log_error("Error: %s %d\n", gai_strerror(r), r);
+
+while (!sd_resolve_is_done(q)) {
+r = sd_resolve_wait(resolve, (uint64_t) -1);
+if (r < 0) {
+log_error("Error: %s\n", strerror(-r));
+assert_not_reached("sd_resolve_wait() failed");
+}
+}
+
+r = sd_resolve_getaddrinfo_done(q, &result);
+if (r < 0) {
log_error("Failed to resolve host %s:%s: %s", node,
service, gai_strerror(r));
return -EHOSTUNREACH;
}
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: prevent timer related memory leaks
From: Lennart Poettering [lenn...@poettering.net] Sent: Thursday, February 20, 2014 8:38 PM To: Umut Tezduyar Lindskog Cc: systemd-devel@lists.freedesktop.org; Umut Tezduyar Lindskog Subject: Re: [systemd-devel] [PATCH] sd-dhcp-client: prevent timer related memory leaks On Thu, 20.02.14 19:49, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: > --- > src/libsystemd-dhcp/sd-dhcp-client.c |6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/src/libsystemd-dhcp/sd-dhcp-client.c > b/src/libsystemd-dhcp/sd-dhcp-client.c > index ec2b53f..84d38f0 100644 > --- a/src/libsystemd-dhcp/sd-dhcp-client.c > +++ b/src/libsystemd-dhcp/sd-dhcp-client.c > @@ -392,6 +392,9 @@ static int client_timeout_resend(sd_event_source *s, > uint64_t usec, > > next_timeout += (random_u32() & 0x1f); > > +if (client->timeout_resend) > +client->timeout_resend = > sd_event_source_unref(client->timeout_resend); > + You can drop the if check btw. We explicitly designed all our _unref() calls so that they are happy with a NULL argument and return NULL in that case... Sure. I also thought about putting an assert on "*ret" in sd_event_add_monotonic once dhcp is fixed. > r = sd_event_add_monotonic(client->event, > &client->timeout_resend, > next_timeout, > @@ -477,6 +480,9 @@ static int client_initialize_events(sd_dhcp_client > *client, > if (r < 0) > goto error; > > +if (client->timeout_resend) > +client->timeout_resend = > sd_event_source_unref(client->timeout_resend); > + > r = sd_event_add_monotonic(client->event, > &client->timeout_resend, > usec, 0, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sd-dhcp-client: prevent timer related memory leaks
--- src/libsystemd-dhcp/sd-dhcp-client.c |4 1 file changed, 4 insertions(+) diff --git a/src/libsystemd-dhcp/sd-dhcp-client.c b/src/libsystemd-dhcp/sd-dhcp-client.c index ec2b53f..53abe22 100644 --- a/src/libsystemd-dhcp/sd-dhcp-client.c +++ b/src/libsystemd-dhcp/sd-dhcp-client.c @@ -392,6 +392,8 @@ static int client_timeout_resend(sd_event_source *s, uint64_t usec, next_timeout += (random_u32() & 0x1f); +client->timeout_resend = sd_event_source_unref(client->timeout_resend); + r = sd_event_add_monotonic(client->event, &client->timeout_resend, next_timeout, @@ -477,6 +479,8 @@ static int client_initialize_events(sd_dhcp_client *client, if (r < 0) goto error; +client->timeout_resend = sd_event_source_unref(client->timeout_resend); + r = sd_event_add_monotonic(client->event, &client->timeout_resend, usec, 0, -- 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] selinux: Only attempt to load policy exactly once, in the real root
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/20/2014 02:27 PM, Eric Paris wrote:
> I like it, if it's reasonable/possible
>
> On Thu, Feb 20, 2014 at 2:26 PM, Lennart Poettering
> wrote:
>> On Thu, 20.02.14 13:50, Eric Paris (epa...@parisplace.org) wrote:
>>
>>> Not really. If it doesn't exist on the final root fs and I put
>>> enforcing=1 on the command line, I expect the box to
>>> panic/fail/die/whatever
>>
>> OK, then maybe check "!in_initrd() || access("/etc/selinux/", F_OK) >=
>> 0"?
>>
>> Lennart
>>
>> -- Lennart Poettering, Red Hat
> ___ Selinux mailing list
> seli...@tycho.nsa.gov To unsubscribe, send email to
> selinux-le...@tycho.nsa.gov. To get help, send an email containing "help"
> to selinux-requ...@tycho.nsa.gov.
You mean
"!in_initrd() || access(selinux_path(), F_OK) >= 0"?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMGW1AACgkQrlYvE4MpobOeUgCg3YoRWatuabfOsAGLD4p09QVo
PYMAn3hDTBy4ePCPy/jORYlE+KGotSxE
=kkZx
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: prevent timer related memory leaks
On Thu, 20.02.14 19:49, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: > --- > src/libsystemd-dhcp/sd-dhcp-client.c |6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/src/libsystemd-dhcp/sd-dhcp-client.c > b/src/libsystemd-dhcp/sd-dhcp-client.c > index ec2b53f..84d38f0 100644 > --- a/src/libsystemd-dhcp/sd-dhcp-client.c > +++ b/src/libsystemd-dhcp/sd-dhcp-client.c > @@ -392,6 +392,9 @@ static int client_timeout_resend(sd_event_source *s, > uint64_t usec, > > next_timeout += (random_u32() & 0x1f); > > +if (client->timeout_resend) > +client->timeout_resend = > sd_event_source_unref(client->timeout_resend); > + You can drop the if check btw. We explicitly designed all our _unref() calls so that they are happy with a NULL argument and return NULL in that case... > r = sd_event_add_monotonic(client->event, > &client->timeout_resend, > next_timeout, > @@ -477,6 +480,9 @@ static int client_initialize_events(sd_dhcp_client > *client, > if (r < 0) > goto error; > > +if (client->timeout_resend) > +client->timeout_resend = > sd_event_source_unref(client->timeout_resend); > + > r = sd_event_add_monotonic(client->event, > &client->timeout_resend, > usec, 0, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
I like it, if it's reasonable/possible
On Thu, Feb 20, 2014 at 2:26 PM, Lennart Poettering
wrote:
> On Thu, 20.02.14 13:50, Eric Paris (epa...@parisplace.org) wrote:
>
>> Not really. If it doesn't exist on the final root fs and I put
>> enforcing=1 on the command line, I expect the box to
>> panic/fail/die/whatever
>
> OK, then maybe check "!in_initrd() || access("/etc/selinux/", F_OK) >= 0"?
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
On Thu, 20.02.14 13:50, Eric Paris (epa...@parisplace.org) wrote:
> Not really. If it doesn't exist on the final root fs and I put
> enforcing=1 on the command line, I expect the box to
> panic/fail/die/whatever
OK, then maybe check "!in_initrd() || access("/etc/selinux/", F_OK) >= 0"?
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
On Thu, Feb 20, 2014 at 1:36 PM, Lennart Poettering
wrote:
On Thu, 20.02.14 18:17, Colin Walters (walt...@verbum.org) wrote:
Hmm, maybe a simple check access("/etc/selinux/", F_OK) would be
enough?
There's no point in trying to initialized SELinux if that dir does not
exist, right? Then we could simply bypass the whole thing...
Beyond what Eric said, I also think that libselinux should continue to
contain all of the key logic for whether or not SELinux is enabled and
how to behave.
The current *API* seems OK in having the two return values of an error
code and an enforcing flag.
The only thing libselinux can't know is:
1) Whether we're inside an initramfs right now
2) Whether or not the OS vendor expects policy to be found in the real
root or the initramfs
So those bits of logic make sense to me in systemd, although there is
an argument for #2 living in libselinux.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sd-dhcp-client: prevent timer related memory leaks
--- src/libsystemd-dhcp/sd-dhcp-client.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/src/libsystemd-dhcp/sd-dhcp-client.c b/src/libsystemd-dhcp/sd-dhcp-client.c index ec2b53f..84d38f0 100644 --- a/src/libsystemd-dhcp/sd-dhcp-client.c +++ b/src/libsystemd-dhcp/sd-dhcp-client.c @@ -392,6 +392,9 @@ static int client_timeout_resend(sd_event_source *s, uint64_t usec, next_timeout += (random_u32() & 0x1f); +if (client->timeout_resend) +client->timeout_resend = sd_event_source_unref(client->timeout_resend); + r = sd_event_add_monotonic(client->event, &client->timeout_resend, next_timeout, @@ -477,6 +480,9 @@ static int client_initialize_events(sd_dhcp_client *client, if (r < 0) goto error; +if (client->timeout_resend) +client->timeout_resend = sd_event_source_unref(client->timeout_resend); + r = sd_event_add_monotonic(client->event, &client->timeout_resend, usec, 0, -- 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] selinux: Only attempt to load policy exactly once, in the real root
On 02/20/2014 01:17 PM, Colin Walters wrote: > On Thu, Feb 20, 2014 at 1:06 PM, Stephen Smalley wrote: >> >> Wouldn't it be better (and more correct) to probe both the initramfs and >> the real root, and if neither one can load policy successfully and >> enforcing=1, then halt? >> > So you're saying we should handle -ENOENT specially in the initramfs? > Something like being sure we preserve errno and returning it to the > caller of selinux_init_load_policy()? That would introduce a subtle > version dependency. > > Or alternatively, just try in the initramfs, ignore any errors, and only > abort if we also fail to load in the real root? > > I think both of these (particularly the second) are worse than my patch > - we don't (to my knowledge) support putting policy in the initramfs now > with Fedora or Red Hat Enterprise Linux, so attempting to find it there > by default on every bootup is wrong. > To turn it around, what is the possible value in also probing the > initramfs? Does anyone out there load policy from it with systemd? Ok, I guess when you put it that way... The only cases I know of where policy is loaded from initramfs are embedded Linux and Android, neither of which are using systemd to my knowledge, and both of which have custom policy loading logic anyway. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
Not really. If it doesn't exist on the final root fs and I put
enforcing=1 on the command line, I expect the box to
panic/fail/die/whatever
On Thu, Feb 20, 2014 at 1:36 PM, Lennart Poettering
wrote:
> On Thu, 20.02.14 18:17, Colin Walters (walt...@verbum.org) wrote:
>
> Hmm, maybe a simple check access("/etc/selinux/", F_OK) would be enough?
> There's no point in trying to initialized SELinux if that dir does not
> exist, right? Then we could simply bypass the whole thing...
>
>> On Thu, Feb 20, 2014 at 1:06 PM, Stephen Smalley
>> wrote:
>> >
>> >Wouldn't it be better (and more correct) to probe both the
>> >initramfs and
>> >the real root, and if neither one can load policy successfully and
>> >enforcing=1, then halt?
>> >
>> So you're saying we should handle -ENOENT specially in the
>> initramfs? Something like being sure we preserve errno and
>> returning it to the caller of selinux_init_load_policy()? That
>> would introduce a subtle version dependency.
>>
>> Or alternatively, just try in the initramfs, ignore any errors, and
>> only abort if we also fail to load in the real root?
>>
>> I think both of these (particularly the second) are worse than my
>> patch - we don't (to my knowledge) support putting policy in the
>> initramfs now with Fedora or Red Hat Enterprise Linux, so attempting
>> to find it there by default on every bootup is wrong.
>>
>> To turn it around, what is the possible value in also probing the
>> initramfs? Does anyone out there load policy from it with systemd?
>>
>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> Selinux mailing list
> seli...@tycho.nsa.gov
> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
On Thu, 20.02.14 18:17, Colin Walters (walt...@verbum.org) wrote:
Hmm, maybe a simple check access("/etc/selinux/", F_OK) would be enough?
There's no point in trying to initialized SELinux if that dir does not
exist, right? Then we could simply bypass the whole thing...
> On Thu, Feb 20, 2014 at 1:06 PM, Stephen Smalley
> wrote:
> >
> >Wouldn't it be better (and more correct) to probe both the
> >initramfs and
> >the real root, and if neither one can load policy successfully and
> >enforcing=1, then halt?
> >
> So you're saying we should handle -ENOENT specially in the
> initramfs? Something like being sure we preserve errno and
> returning it to the caller of selinux_init_load_policy()? That
> would introduce a subtle version dependency.
>
> Or alternatively, just try in the initramfs, ignore any errors, and
> only abort if we also fail to load in the real root?
>
> I think both of these (particularly the second) are worse than my
> patch - we don't (to my knowledge) support putting policy in the
> initramfs now with Fedora or Red Hat Enterprise Linux, so attempting
> to find it there by default on every bootup is wrong.
>
> To turn it around, what is the possible value in also probing the
> initramfs? Does anyone out there load policy from it with systemd?
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] discussions of pkg-config black magic over at gentoo
On Thu, 20.02.14 19:31, Jason A. Donenfeld (ja...@zx2c4.com) wrote: > Hey guys, > > Thought I'd put this discussion upstream. At the moment at Gentoo [1], > we're considering building without the compat-libs, but still with > installing the pkg-config files, so that most out of date packages will > work with a rebuild without having to patch the build system, and we won't > have to ship the old libraries, which is problematic for us because we want > to support ARM. > > So right now we're considering something like this [2] or [3]. A bit of a > bummer to patch the build system like this, but we don't want to rely on > IFUNC, and this seems like the cleanest solution. So I thought I'd mention > this up here in case folks have opinions and such. Harald found a way to do what we want to do without ifunc. Expect this to be fixed shortly in git. And we are likely going to do another release soon. Maybe today, maybe tomorrow. http://willnewton.name/uncategorized/using-gnu-indirect-functions/ Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] discussions of pkg-config black magic over at gentoo
Hey guys, Thought I'd put this discussion upstream. At the moment at Gentoo [1], we're considering building without the compat-libs, but still with installing the pkg-config files, so that most out of date packages will work with a rebuild without having to patch the build system, and we won't have to ship the old libraries, which is problematic for us because we want to support ARM. So right now we're considering something like this [2] or [3]. A bit of a bummer to patch the build system like this, but we don't want to rely on IFUNC, and this seems like the cleanest solution. So I thought I'd mention this up here in case folks have opinions and such. Thanks, Jason [1] https://bugs.gentoo.org/show_bug.cgi?id=501860 [2] https://bugs.gentoo.org/attachment.cgi?id=370894&action=diff [3] https://bugs.gentoo.org/attachment.cgi?id=370896&action=diff ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
On Thu, Feb 20, 2014 at 1:06 PM, Stephen Smalley wrote: Wouldn't it be better (and more correct) to probe both the initramfs and the real root, and if neither one can load policy successfully and enforcing=1, then halt? So you're saying we should handle -ENOENT specially in the initramfs? Something like being sure we preserve errno and returning it to the caller of selinux_init_load_policy()? That would introduce a subtle version dependency. Or alternatively, just try in the initramfs, ignore any errors, and only abort if we also fail to load in the real root? I think both of these (particularly the second) are worse than my patch - we don't (to my knowledge) support putting policy in the initramfs now with Fedora or Red Hat Enterprise Linux, so attempting to find it there by default on every bootup is wrong. To turn it around, what is the possible value in also probing the initramfs? Does anyone out there load policy from it with systemd? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
On 02/20/2014 10:42 AM, Colin Walters wrote: > Currently on at least Fedora, SELinux policy does not come in > the initramfs. systemd will attempt to load *both* in the > initramfs and in the real root. > > Now, the selinux_init_load_policy() API has a regular error return > value, as well as an "enforcing" boolean. To determine enforcing > state, it looks for /etc/selinux/config as well as the presence > of "enforcing=" on the kernel command line. > > Ordinarily, neither of those exist in the initramfs, so it will return > "unknown" for enforcing, and systemd will simply ignore the failure to > load policy. > > Then later after we switch to the real root, we have the config file, > and all will work properly. > > Except...this all blows up if someone explicitly specifies enforcing=1 > on the kernel command line. Then systemd will fail to load the > nonexistent policy in the initramfs and freeze. > > What this patch does is quite simple - we add an internal API that > says where we expect to find policy, and attempt to load it exactly > from there. Right now since I'm not aware of anyone who does > policy-in-initramfs, this function is hardcoded to return false. > > Lots-of-very-painful-debugging-by: Colin Walters > --- > src/core/main.c | 6 -- > src/core/selinux-setup.c | 10 ++ > src/core/selinux-setup.h | 2 ++ > 3 files changed, 16 insertions(+), 2 deletions(-) Wouldn't it be better (and more correct) to probe both the initramfs and the real root, and if neither one can load policy successfully and enforcing=1, then halt? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] It's release time!
On Thu, 2014-02-20 at 02:03 +0100, Lennart Poettering wrote: > On Thu, 20.02.14 01:21, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: > > Even if there can be reasonable style disagreements about exactly where > > to use mixed declarations, at least some uses of them are certainly > > beneficial. It's only a matter of getting used to reading them if you've > > only read old-style code before. I'm sure that if C had had mixed > > declarations from the beginning, nobody would come up with a coding > > style which declared that particular feature to be harmful. > > > > Given systemd's approach to features, I think it's pretty ironic if its > > coding style has a "you can't expect me to get used to new features" > > attitude to something that's been used for more than a decade. > > Oh, it's really not like that. We make use of a lot of newer language > features all the time. We have have a lot of gccisms in our code, such > as the gcc cleanup attribute. And there's already C11 bits in the code, > too. I know that some other new features are used. However, I don't believe that the underlying reason behind opposing mixed declarations would be anything other than being used to lack of it and opposing change. > However, there are certain language features that we consider > obvious improvements and there are others where we are a lot more > conservative. > > It's a matter of taste I figure, it's like tabs vs. spaces. We don't > allow tabs either in our sources... And neither do we allow declaration > after statements... For indentation style, you have to pick _something_ anyway. But you don't have to randomly forbid some normal language features, and the only reason for people to have such a "taste" is being used to old-style sources. There is no reason why people would pick out mixed declarations in particular as something to oppose if it was not a newer feature. If C had had mixed declarations from the beginning, but not the "->" operator, we might have people who are fine mixed declarations but insist that people write (*p).x instead of p->x. Nobody has such a taste now when they haven't become familiar with sources using only such style. > We are apparently not alone on this btw, after all gcc *does* have this > warning flag support even in C99 and C11 mode... Yes, there are people who still want to avoid that. I think they're quite similar to the people who insist that systemd must be only harmful as sysvinit has worked fine for them 20+ years. That's the reason for my comment about irony above. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Remove static_assert related warnings
On Thu, 20.02.14 14:38, Holger Schurig (holgerschu...@gmail.com) wrote:
> Make macro assert_cc() not emit "declaration after statements" warnings.
>
> This can be done by using the GCC pragmas 'diagnostic ignore "undefined"'.
> In order to be able to use that pragma inside a macro, we need to put it
> into the (C99-introduced) _Pragma() pseudo-function.
Ah! Nice! I thought a couple of times about using #pragma for this
but always ran against the wall that #pragma cannot appear in
macros. Thanks for the pointer to _Pragma()! This is a great fix!
I have now commited a change inspired by your patch! Thanks a lot!
> ---
> src/shared/macro.h |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/shared/macro.h b/src/shared/macro.h
> index dfbc201..f93a4f0 100644
> --- a/src/shared/macro.h
> +++ b/src/shared/macro.h
> @@ -156,7 +156,11 @@ static inline size_t ALIGN_TO(size_t l, size_t ali) {
> #if defined(static_assert)
> #define assert_cc(expr) static_assert(expr, #expr)
> #else
> -#define assert_cc(expr) struct UNIQUE(_assert_struct_) { char x[(expr) ? 0 :
> -1]; };
> +#define assert_cc(expr) \
> + _Pragma("GCC diagnostic push"); \
> + _Pragma("GCC diagnostic ignored \"-Wdeclaration-after-statement\""); \
> + struct UNIQUE(_assert_struct_) { char x[(expr) ? 0 : -1]; }; \
> + _Pragma("GCC diagnostic pop");
> #endif
>
> #define assert_return(expr, r) \
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Build warnings for ARM due to -Wcast-align
On 02/20/2014 05:28 PM, Daniel P. Berrange wrote: > On Thu, Feb 20, 2014 at 05:21:22PM +0100, Lennart Poettering wrote: >> I am fine with that. I am personally only running things on x86, so it >> never showed up for me. The usual solution for cast issues is to use >> some union-based type conversion, but in the case above this is not >> really nicely possible. Hence, let's drop it, unless somebody has a >> better solution... > > I think cast align warnings are fairly useful since many things it > can show turn out to be genuine bugs, so not entirely desirable to > disable them altogether. In libvirt we just mark the few cases which > are false positives with a pragma Hmm, but we're talking about ~160 places here. > And then just mark it thus > > VIR_WARNINGS_NO_CAST_ALIGN > ...code with false positive > VIR_WARNINGS_RESET I see your point, but it would really mean to add such things at a lot of places all over the tree. Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] libsytemd is missing move-to-rootlibdir when using split-ur
2014-02-20 17:24 GMT+01:00 Zbigniew Jędrzejewski-Szmek : > On Thu, Feb 20, 2014 at 05:20:05PM +0100, Michael Biebl wrote: >> With split-usr, libsystemd should be installed to /lib, not /usr/lib. >> >> The compat-libs are still correctly installed to /lib, but >> libsystemd.so itself isn't >> >> Will follow up with a patch unless someone beats me to it > > e288d6a81a77? Ah, perfect. Was looking at 209... Btw, could we split this up like this, makes more sense to me this way: diff --git a/Makefile.am b/Makefile.am index 08b94d7..f9df547 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2049,11 +2049,6 @@ libsystemd_la_LIBADD = \ libsystemd-install-hook: libname=libsystemd.so && $(move-to-rootlibdir) - -$(MKDIR_P) $(DESTDIR)/var/log/journal - -chown 0:0 $(DESTDIR)/var/log/journal - -chmod 755 $(DESTDIR)/var/log/journal - -setfacl -nm g:adm:rx,d:g:adm:rx $(DESTDIR)/var/log/journal/ - -setfacl -nm g:wheel:rx,d:g:wheel:rx $(DESTDIR)/var/log/journal/ libsystemd-uninstall-hook: rm -f $(DESTDIR)$(rootlibdir)/libsystemd.so* @@ -3133,6 +3128,19 @@ endif noinst_LTLIBRARIES += \ libsystemd-journal-core.la +journal-install-hook: + -$(MKDIR_P) $(DESTDIR)/var/log/journal + -chown 0:0 $(DESTDIR)/var/log/journal + -chmod 755 $(DESTDIR)/var/log/journal + -setfacl -nm g:adm:rx,d:g:adm:rx $(DESTDIR)/var/log/journal/ + -setfacl -nm g:wheel:rx,d:g:wheel:rx $(DESTDIR)/var/log/journal/ + +journal-uninstall-hook: + -rmdir $(DESTDIR)/var/log/journal/ + +INSTALL_EXEC_HOOKS += journal-install-hook +UNINSTALL_EXEC_HOOKS += journal-uninstall-hook + # -- -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Build warnings for ARM due to -Wcast-align
On Thu, Feb 20, 2014 at 05:21:22PM +0100, Lennart Poettering wrote:
> On Thu, 20.02.14 17:03, Daniel Mack (dan...@zonque.org) wrote:
>
> > Hi,
> >
> > When cross-compiling the current git HEAD for ARM using gcc 4.8.2, I see
> > ~160 warnings similar to this one:
> >
> > src/core/unit.c: In function 'unit_get_exec_runtime':
> > src/core/unit.c:2851:17: warning: cast increases required alignment of
> > target type [-Wcast-align]
> > return *(ExecRuntime**) ((uint8_t*) u + offset);
> > ^
> >
> > The full build log is here:
> >
> > http://paste.fedoraproject.org/78944/92912005
> >
> > Unaligned memory access is indeed unsupported by some older instruction
> > cores. The kernel can fix up in situations where such unaligned access
> > occurs, but that's of course expensive and slow.
> >
> > However, systemd does not actually do unaligned memory access at runtime
> > (at least I haven't seen any when booting up PXA3xx hardware). The
> > warning is simply about the type of pointer arithmetic that casts to and
> > from uint8_t*.
> >
> > And because it's practically impossible to fix the things the compiler
> > complains about here anyway, I propose removing -Wcast-align from the
> > CFLAGS in configure.ac.
> >
> > Any opinions?
>
> I am fine with that. I am personally only running things on x86, so it
> never showed up for me. The usual solution for cast issues is to use
> some union-based type conversion, but in the case above this is not
> really nicely possible. Hence, let's drop it, unless somebody has a
> better solution...
I think cast align warnings are fairly useful since many things it
can show turn out to be genuine bugs, so not entirely desirable to
disable them altogether. In libvirt we just mark the few cases which
are false positives with a pragma
#define VIR_WARNINGS_NO_CAST_ALIGN \
_Pragma ("GCC diagnostic push") \
_Pragma ("GCC diagnostic ignored \"-Wcast-align\"")
#define VIR_WARNINGS_RESET \
_Pragma ("GCC diagnostic pop")
And then just mark it thus
VIR_WARNINGS_NO_CAST_ALIGN
...code with false positive
VIR_WARNINGS_RESET
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] libsytemd is missing move-to-rootlibdir when using split-ur
On Thu, Feb 20, 2014 at 05:20:05PM +0100, Michael Biebl wrote: > With split-usr, libsystemd should be installed to /lib, not /usr/lib. > > The compat-libs are still correctly installed to /lib, but > libsystemd.so itself isn't > > Will follow up with a patch unless someone beats me to it e288d6a81a77? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Build warnings for ARM due to -Wcast-align
On Thu, 20.02.14 17:03, Daniel Mack (dan...@zonque.org) wrote: > Hi, > > When cross-compiling the current git HEAD for ARM using gcc 4.8.2, I see > ~160 warnings similar to this one: > > src/core/unit.c: In function 'unit_get_exec_runtime': > src/core/unit.c:2851:17: warning: cast increases required alignment of > target type [-Wcast-align] > return *(ExecRuntime**) ((uint8_t*) u + offset); > ^ > > The full build log is here: > > http://paste.fedoraproject.org/78944/92912005 > > Unaligned memory access is indeed unsupported by some older instruction > cores. The kernel can fix up in situations where such unaligned access > occurs, but that's of course expensive and slow. > > However, systemd does not actually do unaligned memory access at runtime > (at least I haven't seen any when booting up PXA3xx hardware). The > warning is simply about the type of pointer arithmetic that casts to and > from uint8_t*. > > And because it's practically impossible to fix the things the compiler > complains about here anyway, I propose removing -Wcast-align from the > CFLAGS in configure.ac. > > Any opinions? I am fine with that. I am personally only running things on x86, so it never showed up for me. The usual solution for cast issues is to use some union-based type conversion, but in the case above this is not really nicely possible. Hence, let's drop it, unless somebody has a better solution... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] libsytemd is missing move-to-rootlibdir when using split-ur
With split-usr, libsystemd should be installed to /lib, not /usr/lib. The compat-libs are still correctly installed to /lib, but libsystemd.so itself isn't Will follow up with a patch unless someone beats me to it Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd from git doesn't work with g-object-introspection 1.32.1
On Thu, Feb 20, 2014 at 8:41 AM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Feb 20, 2014 at 01:37:55PM +0100, Holger Schurig wrote: Compilation on Debian Stable, this happens during a make: GISCAN src/gudev/GUdev-1.0.gir Usage: g-ir-scanner [options] sources g-ir-scanner: error: no such option: -W It doesn't have this option here either, afaics. Yes, but the above patch avoids g-ir-scanner having to understand all gcc options - they're wrapped in --cflags-begin ... --cflags-end, injected via Makefile.introspection. Compare the output of a verbose build for you to see. If you want to work around it on the systemd side for old g-i, don't pass warning flags to g-ir-scanner. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Build warnings for ARM due to -Wcast-align
Hi, When cross-compiling the current git HEAD for ARM using gcc 4.8.2, I see ~160 warnings similar to this one: src/core/unit.c: In function 'unit_get_exec_runtime': src/core/unit.c:2851:17: warning: cast increases required alignment of target type [-Wcast-align] return *(ExecRuntime**) ((uint8_t*) u + offset); ^ The full build log is here: http://paste.fedoraproject.org/78944/92912005 Unaligned memory access is indeed unsupported by some older instruction cores. The kernel can fix up in situations where such unaligned access occurs, but that's of course expensive and slow. However, systemd does not actually do unaligned memory access at runtime (at least I haven't seen any when booting up PXA3xx hardware). The warning is simply about the type of pointer arithmetic that casts to and from uint8_t*. And because it's practically impossible to fix the things the compiler complains about here anyway, I propose removing -Wcast-align from the CFLAGS in configure.ac. Any opinions? Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
Currently on at least Fedora, SELinux policy does not come in
the initramfs. systemd will attempt to load *both* in the
initramfs and in the real root.
Now, the selinux_init_load_policy() API has a regular error return
value, as well as an "enforcing" boolean. To determine enforcing
state, it looks for /etc/selinux/config as well as the presence
of "enforcing=" on the kernel command line.
Ordinarily, neither of those exist in the initramfs, so it will return
"unknown" for enforcing, and systemd will simply ignore the failure to
load policy.
Then later after we switch to the real root, we have the config file,
and all will work properly.
Except...this all blows up if someone explicitly specifies enforcing=1
on the kernel command line. Then systemd will fail to load the
nonexistent policy in the initramfs and freeze.
What this patch does is quite simple - we add an internal API that
says where we expect to find policy, and attempt to load it exactly
from there. Right now since I'm not aware of anyone who does
policy-in-initramfs, this function is hardcoded to return false.
Lots-of-very-painful-debugging-by: Colin Walters
---
src/core/main.c | 6 --
src/core/selinux-setup.c | 10 ++
src/core/selinux-setup.h | 2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
>From b109b6e0c1ea7509f08a09d66072c86bea279a06 Mon Sep 17 00:00:00 2001
From: Colin Walters
Date: Thu, 20 Feb 2014 10:15:10 -0500
Subject: [PATCH] selinux: Only attempt to load policy exactly once, in the
real root
Currently on at least Fedora, SELinux policy does not come in
the initramfs. systemd will attempt to load *both* in the
initramfs and in the real root.
Now, the selinux_init_load_policy() API has a regular error return
value, as well as an "enforcing" boolean. To determine enforcing
state, it looks for /etc/selinux/config as well as the presence
of "enforcing=" on the kernel command line.
Ordinarily, neither of those exist in the initramfs, so it will return
"unknown" for enforcing, and systemd will simply ignore the failure to
load policy.
Then later after we switch to the real root, we have the config file,
and all will work properly.
Except...this all blows up if someone explicitly specifies enforcing=1
on the kernel command line. Then systemd will fail to load the
nonexistent policy in the initramfs and freeze.
What this patch does is quite simple - we add an internal API that
says where we expect to find policy, and attempt to load it exactly
from there. Right now since I'm not aware of anyone who does
policy-in-initramfs, this function is hardcoded to return false.
Lots-of-very-painful-debugging-by: Colin Walters
---
src/core/main.c | 6 --
src/core/selinux-setup.c | 10 ++
src/core/selinux-setup.h | 2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/core/main.c b/src/core/main.c
index 58c3a9e..8a13b54 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1296,8 +1296,10 @@ int main(int argc, char *argv[]) {
if (!skip_setup) {
mount_setup_early();
-if (selinux_setup(&loaded_policy) < 0)
-goto finish;
+if (in_initrd() == selinux_load_policy_in_initramfs()) {
+if (selinux_setup(&loaded_policy) < 0)
+goto finish;
+}
if (ima_setup() < 0)
goto finish;
if (smack_setup() < 0)
diff --git a/src/core/selinux-setup.c b/src/core/selinux-setup.c
index 7a32ed5..f689149 100644
--- a/src/core/selinux-setup.c
+++ b/src/core/selinux-setup.c
@@ -37,6 +37,16 @@
#include "util.h"
#include "log.h"
+/**
+ * At present, I'm not aware of a SELinux user who loads the policy
+ * from the initramfs. If you are such a user, you can flip this
+ * define with a patch. Alternatively in the future, this information
+ * could come from the kernel command line.
+ */
+bool selinux_load_policy_in_initramfs(void) {
+return false;
+}
+
#ifdef HAVE_SELINUX
static int null_log(int type, const char *fmt, ...) {
return 0;
diff --git a/src/core/selinux-setup.h b/src/core/selinux-setup.h
index 39e2bc2..d3f3bbc 100644
--- a/src/core/selinux-setup.h
+++ b/src/core/selinux-setup.h
@@ -23,4 +23,6 @@
#include
+bool selinux_load_policy_in_initramfs(void);
+
int selinux_setup(bool *loaded_policy);
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add AppArmor profile switching, v3
3rd version of the patch, taking in account the feedback from Lennart. See http://lists.freedesktop.org/archives/systemd-devel/2014-January/015975.html and http://lists.freedesktop.org/archives/systemd-devel/2014-February/016916.html for details ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add AppArmor profile switching
From: Michael Scherer
This permit to switch to a specific apparmor profile when starting a daemon.
This
will result in a non operation if apparmor is disabled.
It also add a new build requirement on libapparmor for using this feature.
---
Makefile.am | 2 ++
configure.ac | 13 ++
man/systemd.exec.xml | 13 ++
src/core/build.h | 8 +-
src/core/dbus-execute.c | 19 ++
src/core/execute.c| 23
src/core/execute.h| 3 +++
src/core/load-fragment-gperf.gperf.m4 | 3 +++
src/core/load-fragment.c | 49 +++
src/core/load-fragment.h | 1 +
src/shared/exit-status.c | 3 +++
src/shared/exit-status.h | 3 ++-
12 files changed, 138 insertions(+), 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index c71367d..4ac2122 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1016,6 +1016,7 @@ libsystemd_core_la_CFLAGS = \
$(AUDIT_CFLAGS) \
$(CAP_CFLAGS) \
$(KMOD_CFLAGS) \
+ $(APPARMOR_CFLAGS) \
$(SECCOMP_CFLAGS) \
-pthread
@@ -1031,6 +1032,7 @@ libsystemd_core_la_LIBADD = \
$(AUDIT_LIBS) \
$(CAP_LIBS) \
$(KMOD_LIBS) \
+ $(APPARMOR_CFLAGS) \
$(SECCOMP_LIBS)
if HAVE_SECCOMP
diff --git a/configure.ac b/configure.ac
index 05ee098..2521741 100644
--- a/configure.ac
+++ b/configure.ac
@@ -385,6 +385,18 @@ if test "x$enable_selinux" != "xno"; then
fi
AM_CONDITIONAL(HAVE_SELINUX, [test "$have_selinux" = "yes"])
+have_apparmor=no
+AC_ARG_ENABLE(apparmor, AS_HELP_STRING([--disable-apparmor], [Disable optional
AppArmor support]))
+if test "x$enable_apparmor" != "xno"; then
+PKG_CHECK_MODULES([APPARMOR], [libapparmor],
+[AC_DEFINE(HAVE_APPARMOR, 1, [Define if AppArmor is
available]) have_apparmor=yes], have_apparmor=no)
+if test "x$have_apparmor" = xno -a "x$enable_apparmor" = xyes; then
+AC_MSG_ERROR([*** AppArmor support requested but libraries not
found])
+fi
+fi
+AM_CONDITIONAL(HAVE_APPARMOR, [test "$have_apparmor" = "yes"])
+
+
AC_ARG_WITH(debug-shell,
AS_HELP_STRING([--with-debug-shell=PATH],
[Path to debug shell binary]),
@@ -1110,6 +1122,7 @@ AC_MSG_RESULT([
PAM: ${have_pam}
AUDIT: ${have_audit}
IMA: ${have_ima}
+AppArmor:${have_apparmor}
SELinux: ${have_selinux}
SECCOMP: ${have_seccomp}
SMACK: ${have_smack}
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index 7dbe05d..1983993 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -968,6 +968,19 @@
+
AppArmorProfile=
+
+Take a profile name as
argument.
+The process executed by the unit will switch to
+this profile when started. Profiles must
already
+be loaded in the kernel, or the unit will fail.
+This result in a non operation if AppArmor is
not
+enabled. If prefixed by -,
all errors
+will be ignored.
+
+
+
+
IgnoreSIGPIPE=
Takes a boolean
diff --git a/src/core/build.h b/src/core/build.h
index c8117ed..3d7cd3e 100644
--- a/src/core/build.h
+++ b/src/core/build.h
@@ -45,6 +45,12 @@
#define _SELINUX_FEATURE_ "-SELINUX"
#endif
+#ifdef HAVE_APPARMOR
+#define _APPARMOR_FEATURE_ "+APPARMOR"
+#else
+#define _APPARMOR_FEATURE_ "-APPARMOR"
+#endif
+
#ifdef HAVE_IMA
#define _IMA_FEATURE_ "+IMA"
#else
@@ -87,4 +93,4 @@
#define _SECCOMP_FEATURE_ "-SECCOMP"
#endif
-#define SYSTEMD_FEATURES _PAM_FEATURE_ " " _LIBWRAP_FEATURE_ " "
_AUDIT_FEATURE_ " " _SELINUX_FEATURE_ " " _IMA_FEATURE_ " " _SYSVINIT_FEATURE_
" " _LIBCRYPTSETUP_FEATURE_ " " _GCRYPT_FEATURE_ " " _ACL_FEATURE_ " "
_XZ_FEATURE_ " " _SECCOMP_FEATURE_
+#define SYSTEMD_FEATURES _PAM_FEATURE_ " " _LIBWRAP_FEATURE_ " "
_AUDIT_FEATURE_ " " _SELINUX_FEATURE_ " " _IMA_FEATURE_ " " _SYSVINIT_FEATURE_
" " _LIBCRYPTSETUP_FEATURE_ " " _GCRYPT_FEATURE_ " " _ACL_FEATURE_ " "
_XZ_FEATURE_ " " _SECCOMP_FEATURE_ " " _APPARMOR_FEATURE_
diff --git a/src/core/dbus-execute.c b/src/core/dbus-execute.c
index 41dbbab..935c62b 100644
--- a/src/core/dbus-execute.c
+++ b/src/core/dbus-execute.c
@@ -482,6 +482,24 @@ static int property_get_selinux_context(
return sd_bus_message_append(reply, "(bs)", c->selinux_context_igno
[systemd-devel] [PATCH] FIx compilation of nspawn when seccomp is not enabled
From: Michael Scherer --- Makefile.am | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 08b94d7..e4ff7de 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1868,9 +1868,13 @@ systemd_nspawn_LDADD = \ libsystemd-capability.la \ libsystemd-internal.la \ libudev-internal.la \ - libsystemd-shared.la \ + libsystemd-shared.la + +if HAVE_SECCOMP +systemd_nspawn_LDADD += \ libsystemd-seccomp.la \ $(SECCOMP_LIBS) +endif # -- systemd_run_SOURCES = \ -- 1.8.5.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-rtnl: use correct function convention
Hi Jason, On Thu, Feb 20, 2014 at 2:57 AM, Jason A. Donenfeld wrote: > -r = sd_rtnl_call(rtnl, message, 0, NULL); > +r = sd_rtnl_call(rtnl, NULL, message, 0); So this is not 'really' a constructor, so the new convention doesn't apply. The most important thing to me is that we keep sd_rtnl and sd_bus consistent, so I don't think we should change this. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd from git doesn't work with g-object-introspection 1.32.1
$ make -j1 V=1 make --no-print-directory all-recursive Making all in . /usr/bin/g-ir-scanner --c-include=gudev/gudev.h --namespace=GUdev --nsversion=1.0 --libtool="/bin/bash ./libtool" --include=GObject-2.0 --library=libgudev-1.0.la --pkg-export=gudev-1.0 --warn-all -pipe -Wall -Wextra -Wno-inline -Wundef -Wformat=2 -Wformat-security -Wformat-nonliteral -Wlogical-op -Wsign-compare -Wmissing-include-dirs -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wsuggest-attribute=noreturn -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Werror=overflow -Wnested-externs -ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing -fvisibility=hidden -ffunction-sections -fdata-sections -fstack-protector --param=ssp-buffer-size=4 -flto -D_GUDEV_COMPILATION -D_GUDEV_WORK_AROUND_DEV_T_BUG -I./src -I./src -I./src/gudev -I./src/gudev src/gudev/gudev.h src/gudev/gudevtypes.h src/gudev/gudevenums.h src/gudev/gudevenumtypes.h src/gudev/gudevclient.h src/gudev/gudevdevice.h src/gudev/gudevenumerator.h src/gudev/gudevclient.c src/gudev/gudevdevice.c src/gudev/gudevenumerator.c libgudev-1.0.la --output src/gudev/GUdev-1.0.gir Usage: g-ir-scanner [options] sources g-ir-scanner: error: no such option: -W make[2]: *** [src/gudev/GUdev-1.0.gir] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd from git doesn't work with g-object-introspection 1.32.1
On Thu, Feb 20, 2014 at 01:37:55PM +0100, Holger Schurig wrote: > Compilation on Debian Stable, this happens during a make: > > GISCAN src/gudev/GUdev-1.0.gir > Usage: g-ir-scanner [options] sources > > g-ir-scanner: error: no such option: -W It doesn't have this option here either, afaics. What is the full line when you run make with V=1? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd from git doesn't work with g-object-introspection 1.32.1
On Thu, Feb 20, 2014 at 7:37 AM, Holger Schurig wrote: Compilation on Debian Stable, this happens during a make: GISCAN src/gudev/GUdev-1.0.gir When posting errors from builds, always use "make V=1". Usage: g-ir-scanner [options] sources g-ir-scanner: error: no such option: -W g-i 1.32.1 is quite old now...you probably need: https://bugzilla.gnome.org/show_bug.cgi?id=695182 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add setns() functions if not in the C library.
Debian Stable is still using glibc 2.13, which doesn't provide the setns().
So we detect this and provide a tiny wrapper that issues the setns syscall
towards the kernel.
---
configure.ac |3 +++
src/shared/missing.h | 13 +
2 files changed, 16 insertions(+)
diff --git a/configure.ac b/configure.ac
index 05ee098..40162ba 100644
--- a/configure.ac
+++ b/configure.ac
@@ -250,6 +250,9 @@ AC_CHECK_DECLS([gettid, pivot_root, name_to_handle_at], [],
[], [[#include
#include
#include
+#include
#include
#include
#include
@@ -352,4 +353,16 @@ static inline int name_to_handle_at(int fd, const char
*name, struct file_handle
#define O_TMPFILE (__O_TMPFILE | O_DIRECTORY)
#endif
+#ifndef HAVE_SETNS
+static inline int setns(int fd, int nstype)
+{
+#ifdef __NR_setns
+return syscall(__NR_setns, fd, nstype);
+#else
+errno = ENOSYS;
+return -1;
+#endif
+}
+#endif
+
#endif
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Remove static_assert related warnings
Make macro assert_cc() not emit "declaration after statements" warnings.
This can be done by using the GCC pragmas 'diagnostic ignore "undefined"'.
In order to be able to use that pragma inside a macro, we need to put it
into the (C99-introduced) _Pragma() pseudo-function.
---
src/shared/macro.h |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/shared/macro.h b/src/shared/macro.h
index dfbc201..f93a4f0 100644
--- a/src/shared/macro.h
+++ b/src/shared/macro.h
@@ -156,7 +156,11 @@ static inline size_t ALIGN_TO(size_t l, size_t ali) {
#if defined(static_assert)
#define assert_cc(expr) static_assert(expr, #expr)
#else
-#define assert_cc(expr) struct UNIQUE(_assert_struct_) { char x[(expr) ? 0 :
-1]; };
+#define assert_cc(expr) \
+ _Pragma("GCC diagnostic push"); \
+ _Pragma("GCC diagnostic ignored \"-Wdeclaration-after-statement\""); \
+ struct UNIQUE(_assert_struct_) { char x[(expr) ? 0 : -1]; }; \
+ _Pragma("GCC diagnostic pop");
#endif
#define assert_return(expr, r) \
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compilation error on Debian
On Thu, Feb 20, 2014 at 02:21:42PM +0100, Holger Schurig wrote: > Okay, that's easy enought. Can you tell me if "./test-namespace" is > all I need to test it? Or do I have to install the compile systemd > and create a service file with namespace stuff in it? If you write it, anyone can test it by forcing the detection to fail. I don't think you need to test it too extensively. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compilation error on Debian
Okay, that's easy enought. Can you tell me if "./test-namespace" is all I need to test it? Or do I have to install the compile systemd and create a service file with namespace stuff in it? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compilation error on Debian
On Thu, 20.02.14 09:59, Holger Schurig (holgerschu...@gmail.com) wrote: > CC src/core/libsystemd_core_la-namespace.lo > src/core/namespace.c: In function 'setup_netns': > src/core/namespace.c:495:17: warning: implicit declaration of function > 'setns' [-Wimplicit-function-declaration] > src/core/namespace.c:495:17: warning: nested extern declaration of > 'setns' [-Wnested-externs] setns() is not defined in your glibc version. We could surely add a syscall wrapper for that to src/shared/missing.h. We already do that for name_to_handle_at(), fanotify, pivot_root(), gettid(). Hence I don't see why we couldn't add that for setns() too. You'd have to prep the patch though, as I don't have such an old glibc to test against around. You find a lot of inspiration in the current missing.h. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] names: Acquiring name by activator connection logic fixed
On 02/20/2014 12:33 PM, Michal Eljasiewicz wrote:
> This fix allows to register activator connection when
> normal connection already exists for that name.
> Also, when activator connection registers for a second name
> (different than first one) name lookup will
> result in no entry found and checking for multiple names
> will not occur. So checking needs to be done earlier.
>
> Signed-off-by: Michal Eljasiewicz
Makes sense. Applied, thanks!
Daniel
> ---
> names.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/names.c b/names.c
> index c43960a..22ead9f 100644
> --- a/names.c
> +++ b/names.c
> @@ -399,6 +399,13 @@ int kdbus_name_acquire(struct kdbus_name_registry *reg,
>
> mutex_lock(&conn->bus->lock);
> mutex_lock(®->entries_lock);
> +
> + /* an activator can only own a single name */
> + if ((conn->flags & KDBUS_HELLO_ACTIVATOR) && conn->names > 0) {
> + ret = -EALREADY;
> + goto exit_unlock;
> + }
> +
> e = __kdbus_name_lookup(reg, hash, name);
> if (e) {
> /* connection already owns that name */
> @@ -407,9 +414,10 @@ int kdbus_name_acquire(struct kdbus_name_registry *reg,
> goto exit_unlock;
> }
>
> - /* an activator can only own a single name */
> - if (conn->flags & KDBUS_HELLO_ACTIVATOR) {
> - ret = -EALREADY;
> + /* activator registers for name that is already owned */
> + if (conn->flags & KDBUS_HELLO_ACTIVATOR &&
> + e->activator == NULL) {
> + e->activator = kdbus_conn_ref(conn);
> goto exit_unlock;
> }
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd from git doesn't work with g-object-introspection 1.32.1
Compilation on Debian Stable, this happens during a make: GISCAN src/gudev/GUdev-1.0.gir Usage: g-ir-scanner [options] sources g-ir-scanner: error: no such option: -W ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] names: Acquiring name by activator connection logic fixed
This fix allows to register activator connection when
normal connection already exists for that name.
Also, when activator connection registers for a second name
(different than first one) name lookup will
result in no entry found and checking for multiple names
will not occur. So checking needs to be done earlier.
Signed-off-by: Michal Eljasiewicz
---
names.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/names.c b/names.c
index c43960a..22ead9f 100644
--- a/names.c
+++ b/names.c
@@ -399,6 +399,13 @@ int kdbus_name_acquire(struct kdbus_name_registry *reg,
mutex_lock(&conn->bus->lock);
mutex_lock(®->entries_lock);
+
+ /* an activator can only own a single name */
+ if ((conn->flags & KDBUS_HELLO_ACTIVATOR) && conn->names > 0) {
+ ret = -EALREADY;
+ goto exit_unlock;
+ }
+
e = __kdbus_name_lookup(reg, hash, name);
if (e) {
/* connection already owns that name */
@@ -407,9 +414,10 @@ int kdbus_name_acquire(struct kdbus_name_registry *reg,
goto exit_unlock;
}
- /* an activator can only own a single name */
- if (conn->flags & KDBUS_HELLO_ACTIVATOR) {
- ret = -EALREADY;
+ /* activator registers for name that is already owned */
+ if (conn->flags & KDBUS_HELLO_ACTIVATOR &&
+ e->activator == NULL) {
+ e->activator = kdbus_conn_ref(conn);
goto exit_unlock;
}
--
1.8.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus and 32bit architectures
2014-02-20 3:43 GMT+01:00 Kay Sievers : > On Thu, Feb 20, 2014 at 3:19 AM, Peeters Simon > wrote: > Where is it defined on arm? There is an include in kdbus.h. >>> >>> the problem is that it is "#ifndef __KERNEL__" and I assume that >>> __KERNEL__ gets defined when building the module. >> >> both patches attached (sory, didn't bother to try and get git >> send-email to answer to the right thread) > > Cool. Applied the first. > > Instead of the second, I just included "linux/ioctl.h". We should try > to avoid asm-generic/ includes. Please let me know if that works for > you. yes, it does! it now builds completely fine on my beaglebone. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 1/2] Smack - relabel directories and files created by systemd
It was <2014-02-19 śro 20:05>, when Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Feb 19, 2014 at 04:17:15PM +0100, Łukasz Stelmach wrote: >> It was <2014-02-19 śro 16:05>, when Zbigniew Jędrzejewski-Szmek wrote: >> > On Wed, Feb 19, 2014 at 03:44:32PM +0100, Łukasz Stelmach wrote: >> >> How to have support for more than one security fw reasonably >> >> compiled in? (I think this is the moment to create the pattern). >> > Why not? It would be rather constraining for a distribution which wants >> > to support more than one. systemd should just perform the steps necessary >> > for all compiled frameworks compiled in, silently ignoring failures coming >> > from missing frameworks. >> [...] >> The most robust way for systemd is: >> 1) to check in runtime which frameworks are supported, > We have use_selinux(), use_apparmor(), use_smack(). > >> 2) to attempt an action for every one of them, >> 3) to return an error if ANY of the actions fail. > > In general yes, but different frameworks need hooks in different places. > So we generally insert a call to a function specific to a framework, > and inside this function, a use_*() test is performed, and suitably, > either nothing is done or the setup is performed. If an error happens, > it is up to this function to decide whether silent failure, warning, > or an error are warranted. OK, how about this? https://review.tizen.org/git/?p=platform/upstream/systemd.git;a=commitdiff;h=4879ed0a3b3942ed0188c2b5a5633f22847ebe76;hp=6300b3eca9e5261b73bd7f1bb9735992b127cd80 https://review.tizen.org/git/?p=platform/upstream/systemd.git;a=blob;f=src/shared/label.c;h=89939217e3d9bce011c125b504978571e7b57c22;hb=4879ed0a3b3942ed0188c2b5a5633f22847ebe76 -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics pgpPxAeTP7PJE.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus and 32bit architectures
2014-02-20 3:48 GMT+01:00 Greg KH : > On Thu, Feb 20, 2014 at 03:19:09AM +0100, Peeters Simon wrote: >> 2014-02-19 21:03 GMT+01:00 Peeters Simon : >> > 2014-02-19 20:41 GMT+01:00 Kay Sievers : >> >> On Wed, Feb 19, 2014 at 8:34 PM, Peeters Simon >> >> wrote: >> >>> This weekend I switched 2 of my devices to kdbus. both running a 32bit >> >>> system (my atom based netbook and a beaglebone black) >> >>> >> >>> while compiling I ran in to trouble on both devices because of missing >> >>> division and modulo operations for uint64, both related to bloom.size >> >>> in match.c. >> >>> >> >>> So my question is: is it really necessary for bloom.size to be a >> >>> uint64? I can not imagine any use case for bloom sizes exceeding >> >>> UINT32_MAX. >> >>> I am not sure what the proper fix would be, I temporary fixed this by >> >>> casting bloom.size to uint32 where needed, and this works. >> >> >> >> Try changing it to div_u64()? You find that in other places in the >> >> kdbus code too. >> >> >> >> Send a patch please, if it works. >> > >> > will do in a minute (have to get my netbook downstairs) >> > >> >>> I also noted that in kdbus.h (while compiling kdbus itself) ioctl.h >> >>> does not get included resulting in missing definitions for _IO() and >> >>> family. (at least on arm) >> >> >> >> Where is it defined on arm? There is an include in kdbus.h. >> > >> > the problem is that it is "#ifndef __KERNEL__" and I assume that >> > __KERNEL__ gets defined when building the module. >> >> both patches attached (sory, didn't bother to try and get git >> send-email to answer to the right thread) > > The ioctl.h line should include uapi/linux/ioctl.h not an asm-*.h file. > Does that fix the build for you? yes it does, I wasn't sure which one to pic, which is the reason why i didn't add a patch to my first mail. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC] make static_assert() run without warnings
Make C++11 static_assert work without warning by using C99 _Pragma() as well.
---
NOTE: this patch is probably whitespace damaged, because I'm pasting
it in via Google's web interface. I declared this patch as RFC because
I'm unsure how clang behaves on it.
Index: systemd-test/src/shared/macro.h
===
--- systemd-test.orig/src/shared/macro.h 2014-02-20 10:09:53.300892884 +0100
+++ systemd-test/src/shared/macro.h 2014-02-20 10:20:25.656892808 +0100
@@ -156,7 +156,12 @@ static inline size_t ALIGN_TO(size_t l,
#if defined(static_assert)
#define assert_cc(expr) static_assert(expr, #expr)
#else
-#define assert_cc(expr) struct UNIQUE(_assert_struct_) { char
x[(expr) ? 0 : -1]; };
+//#define assert_cc(expr) struct UNIQUE(_assert_struct_) { char
x[(expr) ? 0 : -1]; };
+#define assert_cc(expr) \
+ _Pragma("GCC diagnostic push"); \
+ _Pragma("GCC diagnostic ignored \"-Wdeclaration-after-statement\""); \
+ struct UNIQUE(_assert_struct_) { char x[(expr) ? 0 : -1]; }; \
+ _Pragma("GCC diagnostic pop");
#endif
#define assert_return(expr, r) \
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compilation error on Debian
> You need glibc >= 2.14 Two notes: * than ./configure should say so * that cuts out Debian Stable from the dance, which is probably with us for 2 years ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compilation error on Debian
20.02.2014 on 09:59 Holger Schurig wrote: I'm on Debian 7.4 (the current stable one), gcc is "gcc (Debian 4.7.2-5) 4.7.2". I get lots of warnings, but also a compilation error. I also get one warning at autogen time and one warning at configure time. For the compilation error: I have libc6-dev in version 2.13-38+deb7u1. Doesn't that one define setns? The libc6-dev *.deb provides /usr/include/i386-linux-gnu/bits/syscall.h, which at least defines SYS_setns. [cut] You need glibc >= 2.14 ... CCLD pam_systemd.la libsystemd_internal_la-bus-message.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters /tmp/ccSsUdbL.ltrans11.ltrans.o: In function `namespace_enter': ccSsUdbL.ltrans11.o:(.text+0xf94): undefined reference to `setns' ccSsUdbL.ltrans11.o:(.text+0xfa8): undefined reference to `setns' collect2: error: ld returned 1 exit status make[2]: *** [pam_systemd.la] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 for details please see commit 4ec181a0065102ccb0a8992ed9f2fa4860e44b43 regards, -- Maciej Wereski Samsung R&D Institute Poland Samsung Electronics m.were...@partner.samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Compilation error on Debian
I'm on Debian 7.4 (the current stable one), gcc is "gcc (Debian 4.7.2-5) 4.7.2". I get lots of warnings, but also a compilation error. I also get one warning at autogen time and one warning at configure time. For the compilation error: I have libc6-dev in version 2.13-38+deb7u1. Doesn't that one define setns? The libc6-dev *.deb provides /usr/include/i386-linux-gnu/bits/syscall.h, which at least defines SYS_setns. $ git describe v209-1-g6300b3e $ git clean -fdx $ ./autogen.sh ... configure.ac:37: installing `build-aux/missing' Makefile.am:36: user target `.PRECIOUS' defined here... /usr/share/automake-1.11/am/configure.am: ... overrides Automake target `.PRECIOUS' defined here ... $ ./configure ... checking for LIBGCRYPT - version >= 1.4.5... yes (1.5.0) configure: WARNING: *** *** The config script /usr/bin/libgcrypt-config was *** built for i486-pc-linux-gnu and thus may not match the *** used host i686-pc-linux-gnu. *** You may want to use the configure option --with-libgcrypt-prefix *** to specify a matching config script. *** checking libaudit.h usability... yes ... $ make ... CC src/libsystemd/sd-bus/libsystemd_la-bus-kernel.lo src/libsystemd/sd-bus/bus-kernel.c: In function 'bus_message_setup_kmsg': src/libsystemd/sd-bus/bus-kernel.c:230:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] src/libsystemd/sd-bus/bus-kernel.c: In function 'bus_kernel_create_bus': src/libsystemd/sd-bus/bus-kernel.c:1301:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] src/libsystemd/sd-bus/bus-kernel.c:1302:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] ... CC src/core/libsystemd_core_la-namespace.lo src/core/namespace.c: In function 'setup_netns': src/core/namespace.c:495:17: warning: implicit declaration of function 'setns' [-Wimplicit-function-declaration] src/core/namespace.c:495:17: warning: nested extern declaration of 'setns' [-Wnested-externs] ... CC src/shared/conf-parser.lo src/shared/conf-parser.c: In function 'config_parse_bytes_off': src/shared/conf-parser.c:493:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] ... CCLD libsystemd.la src/libsystemd/sd-bus/.libs/libsystemd_la-bus-message.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters ... CC src/libsystemd/sd-bus/libsystemd_internal_la-bus-kernel.lo src/libsystemd/sd-bus/bus-kernel.c: In function 'bus_message_setup_kmsg': src/libsystemd/sd-bus/bus-kernel.c:230:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] src/libsystemd/sd-bus/bus-kernel.c: In function 'bus_kernel_create_bus': src/libsystemd/sd-bus/bus-kernel.c:1301:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] src/libsystemd/sd-bus/bus-kernel.c:1302:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] ... CCLD libudev.la libsystemd_internal_la-bus-message.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters ... CC src/shared/libsystemd_capability_la-capability.lo src/shared/capability.c: In function 'drop_from_file': src/shared/capability.c:174:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] src/shared/capability.c:175:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] ... CC src/core/libsystemd_core_la-manager.lo src/core/manager.c: In function 'manager_setup_time_change': src/core/manager.c:238:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] CC src/core/libsystemd_core_la-transaction.lo CC src/core/libsystemd_core_la-load-fragment.lo src/core/load-fragment.c: In function 'config_parse_memory_limit': src/core/load-fragment.c:2279:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] ... CC src/core/libsystemd_core_la-dbus-manager.lo src/core/dbus-manager.c: In function 'property_set_runtime_watchdog': src/core/dbus-manager.c:284:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] src/core/dbus-manager.c: In function 'method_get_unit_by_pid': src/core/dbus-manager.c:334:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] ... CC src/core/libsystemd_core_la-namespace.lo src/core/namespace.c: In function 'setup_netns': src/core/namespace.c:495:17: warning: implicit declaration of function 'setns' [-Wimplicit-function-declaration] src/core/namespace.c:495:17: warning: nested extern declaration of 'setns' [-Wnested-externs] ... CC src/udev/net/libudev_core_la-link-config.lo src/udev/net/link-config.c: In function 'get_mac': src/udev/net/link-config.c:334:17: warning: ISO C90 forbids mixed declarations
