Support compile-time disabling of setpriority().

[kyrofa]

This is to support running on systems such as Snappy Ubuntu Core, e.g. heavily confined using seccomp filters with SECCOMP_RET_KILL. In such a situation, without this commit, MySQL is killed as soon as it tries to call setpriority(). With this commit, MySQL can be built without setpriority() by using -DWITH_INNODB_PAGE_CLEANER_PRIORITY=OFF, thus supporting such systems.

[grooverdan]

It looks like MySQL here is doing the right thing here already. Trying to set the priority and showing a information message where it fails. I can't see an abort in the code wrapped.

It looks like the seccomp filters injecting an abort rather than returning EPERM/EACCESS for setpriority is exhibiting the wrong behaviour.

Can the profile for MySQL in Snappy be allowed to perform these syscalls?

Unrelated: the setpriority in buf_flush_page_cleaner_set_priority should have its return value checked.

[mysql-oca-bot]

Hi, thank you for your contribution. Please confirm this code is submitted under the terms of the OCA (Oracle's Contribution Agreement) you have previously signed by cutting and pasting the following text as a comment:
"I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it."
Thanks

[kyrofa]

It looks like MySQL here is doing the right thing here already. Trying to set the priority and showing a information message where it fails. I can't see an abort in the code wrapped.

Ah, my description was perhaps not clear enough. seccomp filters can be configured to handle a non-whitelisted syscall in a number of ways. In the case of snaps, they've chosen SECCOMP_RET_KILL which immediately kills the task making the call (in this case, MySQL). It doesn't get a chance to recover, so it needs to be disabled at compile-time.

It looks like the seccomp filters injecting an abort rather than returning EPERM/EACCESS for setpriority is exhibiting the wrong behaviour.

This is more or less how SECCOMP_RET_KILL works.

Can the profile for MySQL in Snappy be allowed to perform these syscalls?

Not without requiring manual review of every snap containing MySQL, which doesn't scale well. If this PR is acceptable to you, it's a much better solution.

[kyrofa]

I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it.

[mysql-oca-bot]

Hi, thank you for your contribution. Your code has been assigned to an internal queue. Please follow
bug http://bugs.mysql.com/bug.php?id=80931 for updates.
Thanks

[grooverdan]

By adding a compile option there is the overhead of maintaining these as a package.

Seems that application profiles can also set seccomp profiles per application https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement#Seccomp.

If preparing a profile is what was mean by a manual review then the alternate is a manual build of MySQL for every snap containing MySQL. I don't think that scales particularly well either.

SECCOMP_RET_ERRNO could be chosen by the snappy team for system calls that can meaningfully succeed for the caller without executing the syscall. I think this is a better option.

SUMMARY: setpriority shouldn't trigger an abort in Snappy. returning a error message EPERM or a fake success would help more applications than just MySQL.

[kyrofa]

If preparing a profile is what was mean by a manual review then the alternate is a manual build of MySQL for every snap containing MySQL. I don't think that scales particularly well either.

That's exactly how snaps work-- they contain all their dependencies, including MySQL. Every snap that requires MySQL includes it. Which means every one would require a custom profile and thus manual reviews. Or maintain a custom MySQL fork, which is what I do now.

SECCOMP_RET_ERRNO could be chosen by the snappy team for system calls that can meaningfully succeed for the caller without executing the syscall. I think this is a better option.

I agree, but using ERRNO doesn't support logging right now without kernel changes, so the snappy team chose KILL as a more developer-friendly alternative while working on upstreaming the required changes.