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

Clint Byrum spamaps at debian.org
Tue Jan 21 19:51:42 UTC 2014

Excerpts from Kristian Nielsen's message of 2014-01-21 03:18:10 -0800:
> intrigeri <intrigeri at debian.org> writes:
> > Hi,
> >
> > Kristian Nielsen wrote (21 Jan 2014 09:18:05 GMT) :
> >> 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.
> >
> > Thank you for this very useful input. I want to contrast this with:
> >
> >   * Ubuntu has been enabling the MySQL profile by default since 8.04
> >     LTS; perhaps we could ask them how much of a user support mess it
> >     caused.
> >
> >   * Debian does not enable AppArmor by default. So, only people who
> >     explicitly, and manually, enabled it themselves may be affected by
> >     any problems caused by the MySQL AppArmor profile. My assumption
> >     here is that these people are more knowledgeable about AppArmor,
> >     and its potential adverse effects, than the averable Ubuntu +
> >     MySQL user. In particular, I hope they would be able to 1.
> >     guess that a particular problem might be caused by AppArmor; 2.
> >     look at the system log to find out what exact action is blocked;
> >     and 3. add stuff to /etc/apparmor.d/local/.
> >
> > What do you think?
> I think those are valid arguments.
> I think in the end, it comes down to whether one considers apparmor useful. I
> can see the use for apparmor for running eg. proprietary desktop binaries like
> adobe reader or something, to create a kind of sandbox. But for mysqld, I
> don't see much use, only annoyances.

The next time MySQL has an exploit allowing one to write arbitrary
files, the users who have contained their mysqld's with AppArmor will
not be annoyed.

> Others might have different opinions.
> One thing that would be nice is if we could fix the problem that
> mysql-test-run (the test suite) cannot be run when apparmor is enabled. Nor
> can /usr/sbin/mysqld be run as a separate instance by a non-privileged user in
> their own home directory (eg. for testing).
> I am not very familiar with how apparmor works, but one option would seem to
> be to introduce a wrapper /usr/sbin/mysqld_apparmor_wrapper that does nothing
> but call execve() of /usr/sbin/mysqld. Then /etc/init.d/mysql could start the
> wrapper, and the apparmor profile could be tied to the wrapper, and users
> would be free to use /usr/sbin/mysqld for other purposes.
> If supported by apparmor, another option might be to only have the
> restrictions active when /usr/sbin/mysqld is running as the `mysqld' user.
> Put another way, the problem is that the current apparmor profiles prevent a
> number of perfectly valid ways to run /usr/sbin/mysqld. If that problem could
> be solved, then maintaining apparmor profiles would become much more
> attractive.

This is a constant source of confusion caused by Debian's choice to
be a fully-automatic fully-integrated system. Sometimes users just want
binaries. The leaf packages for services like mysql tend to over-reach and
do a mediocre job, but they're liked by many who just want something easy.

My answer there would be to have mysql-server-5.5 and mariadb-server-5.5
contain the apparmor profiles for the users who enable AppArmor. But for
users who want to run mysqld in interesting ways, *-server-core-5.5 has
everything you need to write your own my.cnf and init scripts.

More information about the pkg-mysql-maint mailing list