Ubuntu's community documentation has some basic commands for starting, stopping, disabling, and enabling AppArmor, but if we want to know as little as possible about AppArmor then it's not unlikely that we're just trying to dispense with a plethora of audit complaints in our kernel log. The first time this happened to me, it was on a box which had some MySQL data in a nonstandard location, resulting in a flood of log entries similar to:
Sep 23 11:22:17 bluebeard kernel: [4960023.353512]
audit(1222183337.704:68500): type=1502
operation="inode_permission" requested_mask="r::"
denied_mask="r::" name="/u1/mysql/"
pid=1573 profile="/usr/sbin/mysqld"
namespace="default"
To allow mysqld to do its thing in /u1/mysql without sending AppArmor into a conniption fit, just add permissions to its profile, located by default at /etc/apparmor.d/usr.sbin.mysqld on Ubuntu Hardy systems.
# custom permissions
/u1/mysql/ r,
/u1/mysql/** rwk,
The first line is a comment which makes clear that the lines which follow are not default permissions. The second line grants read access to /u1/mysql/, which AppArmor expects to be a directory due to the trailing slash. The final line uses the /** syntax to specify a group of files and subdirectories, to which are granted access to read, write, and perform locking operations. Note that these rules were simply adapted from the default rules for /var/lib/mysql; such “cut-and-paste” adaptation helps avoid typos and lessens the need for a detailed understanding of the configuration syntax. Note further that this is an observation rather than a recommendation.
Once all profiles have been edited to perfection, reload AppArmor and we're off to the races.
sudo /etc/init.d/apparmor reload
When this information proves inadequate, complete documentation and additional resources can be found at OpenSuse.
No comments:
Post a Comment