[Merge] lp:~jpds/ubuntu/trusty/vsftpd/apparmor-profile into lp:ubuntu/vsftpd

[Jamie Strandboge]

Review: Needs Fixing

Thanks for this!

I think the profile looks ok overall, but I'm quite concerned about the impact on upgrades and new installations. Shipping an enforcing profile by default will break upgrades for sure because the vsftpd/directory may be non-standard. New installations will have the same problem (indeed, there is a debconf entry for this). This is a classic problem for shipping enforcing apparmor policy in highly configuratble and site-dependent server packages. I suggest that you do like we do with rsyslog (which is actually lower risk than vsftpd):
 * disable the profile on new installs
 * disable the profile on upgrades from versions of vsftpd which did not ship an apparmor profile

By doing this, users can opt in to the enforcing apparmor profile (eg, with aa-enforce) and that decision will be preserved on upgrades. The standard way of doing this is doing something like this in preinst:
disable_profile() {
    APP_CONFFILE="/etc/apparmor.d/..."
    APP_DISABLE="/etc/apparmor.d/disable/..."
    # Create a symlink to the yet-to-be-unpacked profile
    if [ ! -e "$APP_CONFFILE" ]; then
        mkdir -p `dirname $APP_DISABLE` 2>/dev/null || true
        ln -sf $APP_CONFFILE $APP_DISABLE
    fi
}

if [ "$1" = "install" ]; then
    # Disable AppArmor profile on install
    disable_profile
elif [ "$1" = "upgrade" ] && dpkg --compare-versions "$2" lt "..." ; then
    # Disable AppArmor on upgrade from earlier than when we first shipped
    # the profile if the user does not already have a profile defined
    disable_profile
fi

-- 
https://code.launchpad.net/~jpds/ubuntu/trusty/vsftpd/apparmor-profile/+merge/199613
Your team Ubuntu branches is subscribed to branch lp:ubuntu/vsftpd.