> So yeah, putting apparmor code before namespace code is the proper fix. I am
> gonna send it
> upstream, and then up to you to decide either to backport/adapt, or to just
> work
> around with /proc being rw.
Patch sent upstream :
http://lists.freedesktop.org/archives/systemd-devel/2014-Octo
On Sun, Oct 12, 2014 at 02:23:22AM +0200, Michael scherer wrote:
> On Sun, Oct 12, 2014 at 01:40:29AM +0200, Michael scherer wrote:
> > So, investigating the problem.
> >
> > The issue is that :
> >
> > ReadOnlyDirectories = /
> >
> > make aa_change_onexec fail with
> >
> > Oct 11 23:22:25 t
On Sun, Oct 12, 2014 at 01:40:29AM +0200, Michael scherer wrote:
> So, investigating the problem.
>
> The issue is that :
>
> ReadOnlyDirectories = /
>
> make aa_change_onexec fail with
>
> Oct 11 23:22:25 test-debian systemd[1985]: Failed at step APPARMOR spawning
> /usr/bin/tor: Read-only
So, investigating the problem.
The issue is that :
ReadOnlyDirectories = /
make aa_change_onexec fail with
Oct 11 23:22:25 test-debian systemd[1985]: Failed at step APPARMOR spawning
/usr/bin/tor: Read-only file system
( once there is proper reporting ). I suspect the issue is upstream, wi
On Sat, Oct 11, 2014 at 10:12:44AM +0200, intrigeri wrote:
> Hi,
>
> Michael Scherer wrote (11 Oct 2014 05:51:39 GMT) :
> > Unfortunately, it seems the error code of aa_change_onexec is not
> > propagated,
> > which is a bug ( my fault, will correct upstream ). In the mean time, I
> > guess
>
Hi,
Michael Scherer wrote (11 Oct 2014 05:51:39 GMT) :
> Unfortunately, it seems the error code of aa_change_onexec is not propagated,
> which is a bug ( my fault, will correct upstream ). In the mean time, I guess
> we will have to use strace and/or gdb to get it and see what is going on.
> I
Unfortunately, it seems the error code of aa_change_onexec is not propagated,
which is a bug ( my fault, will correct upstream ). In the mean time, I guess
we will have to use strace and/or gdb to get it and see what is going on.
I will try to take a look later, once I can find a VM to debug it.
Hi,
intrigeri wrote (24 Sep 2014 05:33:37 GMT) :
> 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.
A
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 "--enab
Hi,
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 didn't: my understanding of the ups
Am 23.09.2014 um 08:51 schrieb intrigeri:
> Hi,
>
> intrigeri wrote (09 Sep 2014 00:14:30 GMT) :
>> So: yes, please. I've been waiting for it eagerly, and will submit
>> patches to the Tor upstream unit file as soon as Debian's systemd
>> supports this option.
>
> I really want this to land in ti
Hi,
intrigeri wrote (09 Sep 2014 00:14:30 GMT) :
> So: yes, please. I've been waiting for it eagerly, and will submit
> patches to the Tor upstream unit file as soon as Debian's systemd
> supports this option.
I really want this to land in time for Jessie, so I've given it a try:
1. added libapp
Hi,
Michael Biebl wrote (05 Sep 2014 00:16:43 GMT) :
> With AppArmor support enabled, services can make use of the
> AppArmorProfile= option [1].
This option is e.g. needed for the systemd unit file for Tor to be
on-par, functionality-wise, with the current initscript we have (a
shell wrapper dir
13 matches
Mail list logo
