What is debian-sys-maint used for?
One major thing it is used for is telling the server to roll the logs. It needs at least the reload and shutdown privilege.
See the file /etc/logrotate.d/mysql-server
It is used by the /etc/init.d/mysql script to get the status of the server. It is used to gracefully shutdown/reload the server.
Here is the quote from the README.Debian
* MYSQL WON'T START OR STOP?:
=============================
You may never ever delete the special mysql user "debian-sys-maint". This user
together with the credentials in /etc/mysql/debian.cnf are used by the init
scripts to stop the server as they would require knowledge of the mysql root
users password else.
What is the easiest way to restore it after I've lost it?
The best plan is to simply not lose it. If you really lose the password, reset it, using another account. If you have lost all admin privileges on the mysql server follow the guides to reset the root password, then repair the debian-sys-maint.
You could use a command like this to build a SQL file that you can use later to recreate the account.
mysqldump --complete-insert --extended-insert=0 -u root -p mysql | grep 'debian-sys-maint' > debian_user.sql
Is the password in
/etc/mysql/debian.cnf already hashed
The password is not hashed/encrypted when installed, but new versions of mysql now have a way to encrypt the credentials (see: https://serverfault.com/a/750363).
I'll start off by saying that FILE is by far the most dangerous privileges you can give to a application. FILE is much more dangerous than GRANT because in sql injection for mysql you cannot stack quires, thus you cannot turn a SELECT into a GRANT statement and there for this privilege is completely useless for sql injection. By contrast FILE privileges are commonly used by exploits to upload a backdoor.
For instance here is an example of sql injection using into outfile
select name from user where id=1 union select "<?php eval($_GET[e])?>" into outfile "/var/www/backdoor.php"
If your try this query on an Ubuntu system it will fail. This is because AppArmor is denying MySQL write access to /var/www/. You could modify AppArmor's rules to deny read/write access to any folder you choose. AppArmor's configuration is pretty straight forward and you can modify it here: /etc/apparmor.d/usr.sbin.mysqld.
If you are on a distro that doesn't support AppArmor you could still use the built-in Linux file permissions, keep in mind that these file io functions are going to be run by the user account that is executing MySQL. chown user -R /some/dir && chmod 700 -R /some/dir.
Best Answer
My preference is to set
log_bin_trust_function_creators = 1to avoid handing out theSUPERpriviledge when it's not required for any other functionality. Appropriate permissions help protect against unknown SQL injection (i.e. user attempts toDROP TABLE) or theft of credentials.Amazon RDS users must also use the second option as RDS does not allow the
SUPERpriviledge. There is an excellent write up on how to set thelog_bin_trust_function_creatorsproperty on RDS instances here.