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'd love to see essentially the regression fixed now for the *default* instance (that is, applying essentially the patch I've proposed on this bug applied, modulo it is now about [email protected]), and then deal separately with confining the non-default instances. In other words, let's first deal with regressions, then polish newly introduced features. What do you think? If we agree on that I'll prepare/test/submit an updated patch and will clone+retitle this bug for the "confine non-default instances" bits. > Any idea how to best deal with apparmor here? Should we create one > /etc/apparmor.d/system_tor like system for each instance? Can we create > them at service start time or do we have to create them at instance > creation time? I've never worked with template units. I'll take a closer look later, but here's a first step. 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 I think we should try that first. Else, we would have to generate the profile at instance creation time. I'd rather not to go this way: I don't want to see all non-default instances broken some day on AppArmor-enabled Debian systems because of obsolete profiles generated many months ago. I'd rather see non-default instances not confined with AppArmor at all, or using a single profile and relying on DAC only for isolating instances from each other. But hopefully we won't even have to think about this case :) > Is there some templating magic we can use? I don't think so. Cheers, -- intrigeri
