1

On an SELinux enabled Oracle Linux 6 host, I have a product using MySQL as its underlying database and, through the database, is trying to access /dev/shm. /dev/shm mounts with context tmpfs_t, by default.

Of course, mysqld_t doesn't have rights to tmpfs_t...

My take is that the best solution is to give the mysqld_t context rights to interact with tmpfs_t, since mysqld_tmp_t and tmp_t are already accessible.

Unfortunately, this getting deeper into the weeds of SELinux than most documentation goes into. Most hints, including Red Hat bug 306351, suggest I add a mount option to /dev/shm to mount it as tmp_t. I'm leaning against that, because I think tmpfs_t is appropriate for /dev/shm.

So, how do I give the mysqld_t type read(), write(), getattr(), setattr(), etc., access to tmpfs_t?

0

It looks like the best choice isn't to do it by hand, but through more SELinux automation.

grep mysqld /var/log/audit/audit.log | grep shm | audit2allow -M mysql_tmpfs

semodule -i mysql_tmpfs.pp

The audit2allow(8) man page says the -M argument uses the next string as the new module name. Between that and the semodule(8) man page, I want to use a module name that doesn't already exist. That way, I avoid accidentally replacing a more complete module with my one-off.

| improve this answer | |
  • (Incidentally, the lack of hash characters at the front of my commands to represent root user prompts is deliberate. With them, someone needs to put considerable effort into copying and pasting the lines for their own use. Without the hashes, someone can just c/p the entire line.) – dafydd Apr 14 '16 at 14:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.