1. we don't want to put the sysctl -w before the systemd-sysctl.service. The userns restriction is disabled before the systemd-systemctl.service runs. So the write before will be a nop, and the systemd-sysctl.service file will then enable the restriction.
2. The apparmor.service is not enabling the restriction, it is done by the systemd-systemctl.service, so I don't have a concern about a race between the apparmor.service and the systed-systemctl.service. 3. If the restriction is enabled there is a window between its enablement and when late* profile load happens, in which a unprivileged process could be blocked from using the restriction. An unprivileged process at this stage is unlikely but services can be launched sandboxed with certain capabilities removed, and that would count. 4. Doing it at the apparmor.service layer does bring in the potential for interaction/race with snapd. snapd has its own service, and its own profile load. * AppArmor profile load is 2 phase. There is an binary cache only load done by systemd very early in boot. This load will only occur to profiles explicitly called out as needing early boot load to minimize the impact on boot as this happens VERY early before parallel operations occur. The second phase is done in the apparmor.service when profiles that don't need to be loaded early are loaded. In this phase the cache is also checked vs. text policy files, and the kernel. If needed the apparmor.service can initiate a recompile, before doing the load. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2122675 Title: Cannot unshare userns in livecd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2122675/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
