[debian-mysql] Bug#736087: Bug#736087: mysql-5.5: Please install AppArmor profile on Debian too

[Kristian Nielsen]

intrigeri at debian.org writes:

> debian/rules only installs the usr.sbin.mysqld AppArmor profile on
> Ubuntu (no idea why this is done in override_dh_installlogrotate-arch,
> by the way; looks like a buggy merge to me, but anyway, that's
> off-topic for now).

In my experience, there are a lot of problems with installing an apparmor
profile by default for the MySQL server. This is from 4 years of experience
maintaining MariaDB .deb packages.

Of course, the actual decision about whether to do it or not should be taken
on a higher level than MariaDB packaging (it should at least be consistent
between MySQL, MariaDB, and Percona Server), but I thought the existing
experiences could be useful, at least.

For a long time on Ubuntu, the MariaDB apparmor package was installed by
default, and of course on Ubuntu apparmor is activated by default. This caused
a lot of problems for our users, who would come to our IRC or mailing list
with strange failures that they did not understand. And probably for each one
who came, there were 10 who just gave up silently.

With MySQL, it is very common to have to access files in various non-standard
places. Eg. to move the data directory (or part of it) to different volumes
for space. Such updates break mysteriously when the user is not aware of the
need to simultaneously update the apparmor profile.

You certainly will need to prevent the installation of a default apparmor
profile when there is an existing /etc/mysql/my.cnf installed by the
user. Otherwise things will certainly break if any stuff has moved to
different directories.

The problem is made worse since the user can test permissions outside of the
mysqld binary and everything will look perfect - only when actually running
the mysqld binary does the error appear. Assuming the user is even capable of
reading the server error logs to see the "permission denied" error in the
first place, many are not.

The fact that apparmor restricts the binary, not the process, just makes the
problem much worse. The permissions really need to be attached to the
_process_, attaching to /usr/sbin/mysqld is just wrong. It is perfectly
possible and sensible to run multiple instances of mysqld at the same time,
and then it makes no sense to have the same permissions for both.

Heck, it is not even possible as a normal user to run the mysql testsuite with
an apparmor profile installed! (As this needs to run lots of /usr/sbin/mysqld
instances in a local directory as a non-root user).

I think things got a milion time better for our users when we finally gave in
and stopped installing the apparmor profile by default in our packages. Lots
of problems solve for the users, and I really do not see any practical
security lost by it (remember that by default we ship with socket listening
only on 127.0.0.1 and running as a separate unprivileged mysql user).

Of course, in the end it is up to people more involved in the distros to
decide (For myself, I've long since learned to just disable apparmor :-)

Hope this helps,

 - Kristian.