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

[Robie Basak]

I've just submitted a patch for this:

http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-February/006409.html

I'd like to counter some of your points, as I think it does make sense
for Debian to cover this. I do have an ulterior motive here, though,
which is that carrying this in Debian will reduce the size of the Ubuntu
delta, and thus cause less work for me.

Summary: most of your arguments are true for AppArmor generally, rather
than specifically for MySQL packaging. Since AppArmor is optional in
Debian, users who choose to use AppArmor accept these things by
choosing to use AppArmor in the first place. Thus, it doesn't make sense
to hold back from adding AppArmor profiles in the first place, since
users are opting in already.

On Tue, Jan 21, 2014 at 10:18:05AM +0100, Kristian Nielsen wrote:
> 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.

Agreed. I often get bitten by AppArmor in this way too, by forgetting to
check dmesg. But this is a consequence of using AppArmor on a server
system generally and isn't specific to MySQL.

> 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.

I think it is acceptable to expect the user to modify the shipped
AppArmor profile if he chooses to alter the paths of things on his
system; this is an accepted consequence of choosing to use AppArmor in
the first place.

> 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.

This is also a general consequence of using AppArmor.

> 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.

AppArmor can do this - using aa-exec(1) and non-attaching profiles, you
can start multiple instances of mysqld contrained by different profiles.

> 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).

Good point. Perhaps this one should be special cased with a wrapper, as
you describe elsewhere.

> 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 :-)

You make good arguments as to whether AppArmor should be installed by
default. But I think that all your points are covered by Debian not
installing AppArmor by default today. I don't think it should be for
individual packages to override the user's choice of installing AppArmor
by then not shipping profiles. By installing AppArmor, he already makes
the choice, and it is acceptable for packages to then honor that choice
by shipping profiles.

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20140210/465309c6/attachment.sig>