Control: tag -1 + patch

Hi,

intrigeri wrote (23 Sep 2014 17:01:21 GMT) :
> Michael Biebl wrote (23 Sep 2014 11:59:22 GMT) :
>>> a) I don't see any dependency automatically added on libapparmor1, and
>>>    I've no idea which binary package exactly should have it. Any hint?

>> Did you add "--enable-apparmor" to the configure flags?

I tried it, and indeed the binary systemd package now Depends:
libapparmor1 (>= 2.6~devel). Thanks!

So, only problem (b) remains. I was able to workaround it by
commenting out these directives in the unit file:

  ReadOnlyDirectories = /
  ReadWriteDirectories = /var/lib/tor 
  ReadWriteDirectories = /var/log/tor
  ReadWriteDirectories = /var/run/tor

Note that for some reason, leaving this directive in is not a problem,
though:

  InaccessibleDirectories = /home

And adding these directives works too:

  ProtectSystem = full
  ProtectHome = yes

To make sure this problem wasn't caused by the old apparmor package we
have, I've prepared a 2.8.96~2652-1 apparmor package yesterday, which
is now in experimental, and rebuilt systemd against it. Then, I've
tested the resulting systemd packages on a system that has apparmor
2.8.96~2652-1 from experimental, and I see the same problem, the and
same workaround applies.

Should we take this problem upstream? I've not subscribed to the
systemd ML, and never interacted with them yet, so I'd rather see you
do that. Still, if you can't or don't want to do it, I guess I can try
to find time to learn how to communicate with yet another friendly
upstream community... during the Jessie+1 dev cycle.

In any case:

 * According to codesearch, there's exactly zero unit file in Debian
   currently that uses AppArmorProfile= (not a surprise, considering
   systemd doesn't support it in Debian yet), let alone combined with
   Read{Only,Write}Directories.

 * As far as the Tor unit file is concerned, the
   Read{Only,Write}Directories directives are not part of the unit
   file shipped upstream in the version (0.2.5.x) that will be in
   Jessie, so that's not a real problem yet, and we can add
   AppArmorProfile= in there. These directories are in Tor 0.2.6.x,
   though, so we'll have to handle it somehow for Jessie+1.

So, I don't think that the problem I'm seeing here is a blocker for
enabling AppArmor support in systemd. The attached patch implements
this. Once something like this is applied, I'll clone this bug report
to track the remaining problems.

Cheers,
-- 
intrigeri

>From 6157f1c74e55189cf663904bef429b36dcc2a48f Mon Sep 17 00:00:00 2001
From: intrigeri <intrig...@debian.org>
Date: Tue, 23 Sep 2014 04:57:13 +0000
Subject: [PATCH] Enable AppArmor support (Closes: #760526)

- add build-dependency on libapparmor-dev
- add --enable-apparmor to the configure flags
---
 debian/control | 1 +
 debian/rules   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/debian/control b/debian/control
index f27beb9..3c02037 100644
--- a/debian/control
+++ b/debian/control
@@ -21,6 +21,7 @@ Build-Depends: debhelper (>= 9),
                autoconf (>= 2.63),
                intltool,
                gperf,
+               libapparmor-dev,
                libcap-dev,
                libpam0g-dev,
                libaudit-dev,
diff --git a/debian/rules b/debian/rules
index 5a0b8c3..d371d72 100755
--- a/debian/rules
+++ b/debian/rules
@@ -25,6 +25,7 @@ CONFFLAGS = \
 	--disable-microhttpd \
 	--disable-sysusers \
 	--disable-silent-rules \
+	--enable-apparmor \
 	--with-ntp-servers="0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org"  \
 	--with-system-uid-max=999 \
 	--with-system-gid-max=999
-- 
2.1.1

_______________________________________________
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Reply via email to