> Previously we only had the option of using a system wide sysctl
> kernel.unprivileged_userns_clone to disable unprivileged user
> namespaces. Debian defaults this to off, and you have to opt in.
Just to avoid misunderstandings (I failed to parse the above sentence
unambiguously): in Debian, unpr
I see this is "Fix Released" everywhere but on the upstream AppArmor
project. I understand this has made its way upstream and works with
mainline kernel, e.g. for LXC. If my understanding is incorrect, please
clarify what's left to do here (or perhaps track it on a finer-grained
follow-up bug :)
*
It seems to me this was fixed & released a while ago.
https://bugs.launchpad.net/apparmor/+bug/1384746/comments/2 could be
tracked on a new, follow-up bug, if still desired.
** Changed in: apparmor
Status: In Progress => Fix Released
--
You received this bug notification because you are
Meta: I've re-read the discussion from December 2017. If there were
messages later than this on the thread, I missed them due to suboptimal
mailing list archive presentation. Sorry if this leads me to wrong
conclusions!
I lack the skills to do the actual work I think should be done. The only
way I
FTR this was raised as a potential blocker for enabling AppArmor by
default on Debian: https://bugs.debian.org/872726. I'm going to
investigate why this is a blocker there.
tl;dr: as the audit maintainers said in 2014
(https://www.redhat.com/archives/linux-audit/2014-May/msg00119.html) and
2016 (h
Hi! What kind of (realistic) timeline can we expect here? (With the move
to ZFS for containers, I wonder :)
E.g. is this part of your goals for 16.10? (I mean: for the AppArmor
/Ubuntu-specific parts, as I've learnt to be patient wrt. the
upstreaming to Linux mainline.)
Thanks for your work on Ap
6 matches
Mail list logo
