Hi,
Peter Palfrader wrote (20 Oct 2015 18:50:38 GMT) :
> On Tue, 20 Oct 2015, intrigeri wrote:
>> If AppArmorProfile= is applied _after_ ExecStartPre=, then we can
>> probably use the latter to dynamically generate a per-instance profile
>> from within a unit file itself. This would be ideal, and
On Tue, 20 Oct 2015, intrigeri wrote:
> Meta: I've been working for years to have the move to systemd not
> introduce a regression for us on the AppArmor front, and it currently
> does ⇒ I'd love to see essentially the regression fixed now for the
> *default* instance (that is, applying essentiall
Control: tag -1 - patch
Hi,
Peter Palfrader wrote (19 Oct 2015 17:43:23 GMT) :
> The Debian package for Tor now supports multiple instances.
Great \o/
Meta: I've been working for years to have the move to systemd not
introduce a regression for us on the AppArmor front, and it currently
does ⇒ I
On Wed, 12 Aug 2015, intrigeri wrote:
> Control: tag -1 + patch
>
> Hi weasel,
>
> this does the job for me:
>
> --- a/debian/tor.service
> +++ b/debian/tor.service
> @@ -17,11 +17,13 @@ Restart=on-failure
> LimitNOFILE=65536
>
> # Hardening
> +AppArmorProfile=system_tor
The Debian package
Control: tag -1 + patch
Hi weasel,
this does the job for me:
--- a/debian/tor.service
+++ b/debian/tor.service
@@ -17,11 +17,13 @@ Restart=on-failure
LimitNOFILE=65536
# Hardening
+AppArmorProfile=system_tor
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDi
Package: tor
Version: 0.2.5.6-alpha-1
Severity: wishlist
Hi,
as mentioned on #761403:
Another change that we'll want to make is to use the AppArmorProfile=
unit file directive, to avoid a regression for AppArmor users.
This option only exists in systemd v210+ (and I had it added precisely
to sup
6 matches
Mail list logo
