[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] 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 walt...@verbum.org
---
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 walt...@verbum.org
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 walt...@verbum.org
---
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 stdbool.h
+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
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 zbys...@in.waw.pl 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] 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] 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
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, 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
2014-02-20 17:24 GMT+01:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: 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] [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] [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] 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 walt...@verbum.org --- 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] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
On Thu, Feb 20, 2014 at 1:06 PM, Stephen Smalley s...@tycho.nsa.gov 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
[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=370894action=diff [3] https://bugs.gentoo.org/attachment.cgi?id=370896action=diff ___ 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
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 s...@tycho.nsa.gov 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] [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 lenn...@poettering.net 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 s...@tycho.nsa.gov 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 02/20/2014 01:17 PM, Colin Walters wrote: On Thu, Feb 20, 2014 at 1:06 PM, Stephen Smalley s...@tycho.nsa.gov 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
[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 Thu, Feb 20, 2014 at 1:36 PM, Lennart Poettering lenn...@poettering.net 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
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
I like it, if it's reasonable/possible On Thu, Feb 20, 2014 at 2:26 PM, Lennart Poettering lenn...@poettering.net 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] 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
-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 lenn...@poettering.net 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
[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] 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] [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] selinux: Only attempt to load policy exactly once, in the real root
On Thu, Feb 20, 2014 at 2:45 PM, Daniel J Walsh dwa...@redhat.com 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
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 walt...@verbum.org wrote: On Thu, Feb 20, 2014 at 2:45 PM, Daniel J Walsh dwa...@redhat.com 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] Build warnings for ARM due to -Wcast-align
On Thu, Feb 20, 2014 at 5:03 PM, 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? 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
On Thu, Feb 20, 2014 at 4:10 PM, Eric Paris epa...@parisplace.org 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
[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
[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
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] [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] [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
Re: [systemd-devel] Docker, Supervisor and systemd
On Thu, Feb 20, 2014 at 2:25 PM, Paul Menzel paulepan...@users.sourceforge.net 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] [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] 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 paulepan...@users.sourceforge.net: 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] selinux: Only attempt to load policy exactly once, in the real root
On Thu, Feb 20, 2014 at 4:21 PM, Colin Walters walt...@verbum.org
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 walt...@verbum.org
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 walt...@verbum.org
---
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 stdbool.h
-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] [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 sys/
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 fcntl.h
#include stdlib.h
#include unistd.h
+#include errno.h
#include linux/oom.h
#include linux/input.h
#include linux/if_link.h
@@ -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] 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 m...@zarb.org --- 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] 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 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? 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] 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
[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] [PATCH] Add AppArmor profile switching
On Thu, 20.02.14 16:19, m...@zarb.org (m...@zarb.org) wrote: From: Michael Scherer m...@zarb.org 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] 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
[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
[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
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?
-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] 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
[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
Re: [systemd-devel] Compilation error on Debian
20.02.2014 on 09:59 Holger Schurig holgerschu...@gmail.com 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 RD 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
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
[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] kdbus and 32bit architectures
2014-02-20 3:48 GMT+01:00 Greg KH gre...@linuxfoundation.org: On Thu, Feb 20, 2014 at 03:19:09AM +0100, Peeters Simon wrote: 2014-02-19 21:03 GMT+01:00 Peeters Simon peeters.si...@gmail.com: 2014-02-19 20:41 GMT+01:00 Kay Sievers k...@vrfy.org: On Wed, Feb 19, 2014 at 8:34 PM, Peeters Simon peeters.si...@gmail.com 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
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 RD 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:43 GMT+01:00 Kay Sievers k...@vrfy.org: On Thu, Feb 20, 2014 at 3:19 AM, Peeters Simon peeters.si...@gmail.com 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
[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 m.eljasie...@samsung.com
---
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(reg-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
[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
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 m.eljasie...@samsung.com
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(reg-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
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, 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
[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
[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 sys/
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 fcntl.h
#include stdlib.h
#include unistd.h
+#include errno.h
#include linux/oom.h
#include linux/input.h
#include linux/if_link.h
@@ -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
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 holgerschu...@gmail.com 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
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
$ 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] [PATCH] sd-rtnl: use correct function convention
Hi Jason, On Thu, Feb 20, 2014 at 2:57 AM, Jason A. Donenfeld ja...@zx2c4.com 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
[systemd-devel] [PATCH] FIx compilation of nspawn when seccomp is not enabled
From: Michael Scherer m...@zarb.org --- 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
[systemd-devel] [PATCH] Add AppArmor profile switching
From: Michael Scherer m...@zarb.org
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 @@
/varlistentry
varlistentry
+
termvarnameAppArmorProfile=/varname/term
+
+listitemparaTake 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 literal-/literal,
all errors
+will be ignored.
+/para/listitem
+/varlistentry
+
+varlistentry
termvarnameIgnoreSIGPIPE=/varname/term
listitemparaTakes 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
