Thanks, I managed to fix /var/lib/mysql # ls -ldZ /var/lib/mysql drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 /var/lib/mysql To fix it, I tried: semanage fcontext -d -e /var/lib/mysql this command returned: KeyError: /var/lib/mysql I tried restorecon anyway: restorecon -Rv /var/lib/mysql But not better: ls -ldZ /var/lib/mysql drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0 /var/lib/mysql So I did the following: semanage fcontext -d -t var_lib_t /var/lib/mysql It started to look better: ls -ldZ /var/lib/mysql drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0 /var/lib/mysql Then I ran restorecon restorecon -Rv /var/lib/mysql I got a lot of : restorecon reset /var/lib/mysql/... And then I got the proper context on /var/lib/mysql. I think there are still many things I do not understand about SELinux. I thought the equivalence thing I did with the command below was going to assign the context of /var/lib/mysql.old to /var/lib/mysql. Obviously not! semanage fcontext -a -e /var/lib/mysql.old /var/lib/mysql I still have the following equivalence: # semanage fcontext -lC SELinux fcontext type Context /home/users(/.*)? all files system_u:object_r:user_home_dir_t:s0 /var/lib/mysql all files system_u:object_r:mysqld_db_t:s0 /var/lib/mysql(/.*)? all files system_u:object_r:mysqld_db_t:s0 SELinux Local fcontext Equivalence ./mysql = ./mysql.old mysql = ./mysql.old Should I be worried about those two equivalence? Thanks, Bernard On Mon, Oct 23, 2017 at 1:41 PM, James Hogarth <james.hogarth at gmail.com> wrote:> On 23 Oct 2017 5:26 pm, "Bernard Fay" <bernard.fay at gmail.com> wrote: > > Interesting to see the Equivalence. As a first thing, I tried: > > semanage fcontext -a -e /var/lib/mysql.old /var/lib/mysql > then > restorecon -R /var/lib/mysql > > > # semanage fcontext -lC > SELinux fcontext type > Context > > /home/users(/.*)? all files > system_u:object_r:user_home_dir_t:s0 > /var/lib/mysql all files > system_u:object_r:mysqld_db_t:s0 > /var/lib/mysql(/.*)? all files > system_u:object_r:mysqld_db_t:s0 > > SELinux Local fcontext Equivalence > > ./mysql = ./mysql.old > /var/lib/mysql = /var/lib/mysql.old > mysql = ./mysql.old > > > > > On Mon, Oct 23, 2017 at 10:27 AM, James Hogarth <james.hogarth at gmail.com> > wrote: > > > On 23 October 2017 at 13:33, Bernard Fay <bernard.fay at gmail.com> wrote: > > > Hello, > > > > > > A server was configured in /var/lib/myslq in the root fs. I added a LV > > > specifically for mysql. I stopped myql and renamed /var/lib/mysql to > > > /var/lib/mysql.old. I created a new dir /var/lib/mysql and mounted the > > LV > > > on /var/lib/mysql. I then copied with "cp -prZ" all mysql files in > > > /var/lib/mysql.old to /var/lib/mysql. > > > > > > But then I got a selinux problem: > > > # ls -ldZ mysql.old/ mysql > > > drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0 mysql > > > drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql.old/ > > > > > > I tried to changed the context on mysql with the following commands: > > > > > > # semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?" > > > # restorecon -R -v /var/lib/mysql > > > > > > But the /var/lib/mysql directory didn't take the change as you can see > > > below: > > > # ls -ldZ mysql.old/ mysql > > > drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0 mysql > > > drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql.old/ > > > > > > > > > How can I fix the wrong context on mysql directory? > > > Thanks, > > > > > > > /var/lib/mysql is already in default policy - no need to add anything > there > > > > can you please provide the output of 'semanage fcontext -lC' so that > > we can see any local selinux modifications made? > > > > From base policy with nothing added, for that directory, you *should* > > be able to just restorecon -Rv /var/lib/mysql and have the correct > > labelling. > > _______________________________________________ > > CentOS mailing list > > CentOS at centos.org > > https://lists.centos.org/mailman/listinfo/centos > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos > > > The equivalence is what has broken things for you then. > > Remember that the source of Truth for labels don't follow the files > themselves. > > Looking at that it appears you told selinux that your local config should > have /var/lib/mysql match /var/lib/mysql.old ... note well the ordering > there. > > The system policy for the latter will inherit from /var/lib as mysql.old is > not a directory that is in the normal config. > > This "local config" making /var/lib/mysql in the policy match > /var/lib/mysql.old is now overriding the default system config ... which is > why restorecon is setting it to var_lib_t and not the mysql type. > > If you restorecon on /var/lib/mysql.old this will be evident. > > The fix is to semanage fcontext -d -e /var/lib/mysql to remove that > incorrect local equivalence overriding base policy and then to restorecon > -Rv /var/lib/mysql to put in place the correct labels. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >
James Hogarth
2017-Oct-23 21:13 UTC
[CentOS] Unable to apply mysqld_db_t to mysql directory
On 23 October 2017 at 19:18, Bernard Fay <bernard.fay at gmail.com> wrote:> Thanks, I managed to fix /var/lib/mysql > > # ls -ldZ /var/lib/mysql > drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 /var/lib/mysql > > To fix it, I tried: > semanage fcontext -d -e /var/lib/mysql > this command returned: > KeyError: /var/lib/mysql > I tried restorecon anyway: > restorecon -Rv /var/lib/mysql > But not better: > ls -ldZ /var/lib/mysql > drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0 /var/lib/mysql > > So I did the following: > semanage fcontext -d -t var_lib_t /var/lib/mysql > It started to look better: > ls -ldZ /var/lib/mysql > drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0 /var/lib/mysql > Then I ran restorecon > restorecon -Rv /var/lib/mysql > I got a lot of : > restorecon reset /var/lib/mysql/... > > And then I got the proper context on /var/lib/mysql. > > > I think there are still many things I do not understand about SELinux. > > I thought the equivalence thing I did with the command below was going to > assign the context of /var/lib/mysql.old to /var/lib/mysql. Obviously not! > semanage fcontext -a -e /var/lib/mysql.old /var/lib/mysql > >I think you have a slight misconception over how labels are determined. There's no relation between what is presently on the filesystem when you do ls -lZ and what the policy database thinks it ought to be. This is why you can chcon to change the label of something but a relabelling will change it back. When you run restorecon to relabel a path what happens is it takes the absolute (full) path and compares it against the regexes in the selinux policy database (see it with semanage fcontext -l for some, but now all, context matches) ... Then for the most specific match it will apply whatever label is in that database. When you do semanage fcontext -a -e /foo /bar to do an alias what you are telling selinux is that for every time that /bar is run through the regex replace bar with foo and check that instead. This is why when adding custom labelling you need to do a full regex path to match files under that directory too. When you moved /var/lib/mysql to /var/lib/mysql.old the labels moved with the files (this is the default unless you cross filesystems, you can force labelling as the destination with mv -Z). The selinux database still has /var/lib/mysql(/.*)? as being type mysqldb_db_t even if that directory doesn't exist. When the directory is created and put in place then it will get what policy says is right for that path. The point of using equivalence is when you move a default location - such as /home to /data/home or /var/lib/mysql to /data/mysql In that situation the default selinux policy doesn't know anything about /data or the contents of it so it'll end up with a default_t label ... not very useful. Now you could semanage fcontext -a -t mysqldb_db_t /data/mysql(/.*)? but quite often the 'story' of a directory tree isn't about just one label and it'd be tedious trying to match them all ... For the craziness that is $HOME for instance... CentOS7: cat /etc/selinux/targeted/contexts/files/file_contexts.homedirs Fedora: cat /usr/share/selinux/targeted/default/active/homedir_template There's a lot of different contexts depending on the file in that tree ... trying to mimic them all to move /home to /data/home would be a nightmare ... But this is made trivial with semanage fcontext -a -e /home /data/home to ensure ~/.ssh and ~/.gpg and ~/public_html and so on all get the right contexts. So based on that I hope you understand why the equivalence lines you have left are effectively meaningless - they are not absolute paths and so can't match a tree to do the labelling replacement. Does that help make things a bit clearer on your file contexts? TL:DR; there was no need to "assign" as you were still using the default mysql DB path, just a restorecon would have solved it.
James, I read your email a couple of times. There is so much to learn from it. If I am right, the output of "semanage fcontext -l" is the content of the SELinux database regarding the SELinux contexts. Yet if I am right, when we try to assign or verify what should be the contexts on files or directories, a first look at the SELinux DB should be the first thing to do. Right? I have now a much better understanding of what is going on when I use "semanage fcontext -a -t ..." then "restorecon -R". "semanage fcontext -a" add fcontext the SELinux DB and restorecon applies the fcontext to the files or directory as defined in the DB. In the past I have been confused by chcon and came to the conclusion this command was totally useless. But if the command exist, it should have a use of it. What kind of situation could make chcon useful? Regarding the equivalence, at first I understood it as "make this equal to that". A bit like when using chmod --reference. Wrong!!! I didn't only have a slight misconception on label, I honestly would say I was lost with the new lights you made on it. Thanks a lot for your time James! I really appreciate it. Bernard On Mon, Oct 23, 2017 at 5:13 PM, James Hogarth <james.hogarth at gmail.com> wrote:> On 23 October 2017 at 19:18, Bernard Fay <bernard.fay at gmail.com> wrote: > > Thanks, I managed to fix /var/lib/mysql > > > > # ls -ldZ /var/lib/mysql > > drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 /var/lib/mysql > > > > To fix it, I tried: > > semanage fcontext -d -e /var/lib/mysql > > this command returned: > > KeyError: /var/lib/mysql > > I tried restorecon anyway: > > restorecon -Rv /var/lib/mysql > > But not better: > > ls -ldZ /var/lib/mysql > > drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0 /var/lib/mysql > > > > So I did the following: > > semanage fcontext -d -t var_lib_t /var/lib/mysql > > It started to look better: > > ls -ldZ /var/lib/mysql > > drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0 /var/lib/mysql > > Then I ran restorecon > > restorecon -Rv /var/lib/mysql > > I got a lot of : > > restorecon reset /var/lib/mysql/... > > > > And then I got the proper context on /var/lib/mysql. > > > > > > I think there are still many things I do not understand about SELinux. > > > > I thought the equivalence thing I did with the command below was going to > > assign the context of /var/lib/mysql.old to /var/lib/mysql. Obviously > not! > > semanage fcontext -a -e /var/lib/mysql.old /var/lib/mysql > > > > > > I think you have a slight misconception over how labels are determined. > > There's no relation between what is presently on the filesystem when > you do ls -lZ and what the policy database thinks it ought to be. > > This is why you can chcon to change the label of something but a > relabelling will change it back. > > When you run restorecon to relabel a path what happens is it takes the > absolute (full) path and compares it against the regexes in the > selinux policy database (see it with semanage fcontext -l for some, > but now all, context matches) ... > > Then for the most specific match it will apply whatever label is in > that database. > > When you do semanage fcontext -a -e /foo /bar to do an alias what you > are telling selinux is that for every time that /bar is run through > the regex replace bar with foo and check that instead. > > This is why when adding custom labelling you need to do a full regex > path to match files under that directory too. > > When you moved /var/lib/mysql to /var/lib/mysql.old the labels moved > with the files (this is the default unless you cross filesystems, you > can force labelling as the destination with mv -Z). > > The selinux database still has /var/lib/mysql(/.*)? as being type > mysqldb_db_t even if that directory doesn't exist. > > When the directory is created and put in place then it will get what > policy says is right for that path. > > The point of using equivalence is when you move a default location - > such as /home to /data/home or /var/lib/mysql to /data/mysql > > In that situation the default selinux policy doesn't know anything > about /data or the contents of it so it'll end up with a default_t > label ... not very useful. > > Now you could semanage fcontext -a -t mysqldb_db_t /data/mysql(/.*)? > but quite often the 'story' of a directory tree isn't about just one > label and it'd be tedious trying to match them all ... > > For the craziness that is $HOME for instance... > > CentOS7: cat /etc/selinux/targeted/contexts/files/file_contexts.homedirs > Fedora: cat /usr/share/selinux/targeted/default/active/homedir_template > > There's a lot of different contexts depending on the file in that tree > ... trying to mimic them all to move /home to /data/home would be a > nightmare ... > > But this is made trivial with semanage fcontext -a -e /home /data/home > to ensure ~/.ssh and ~/.gpg and ~/public_html and so on all get the > right contexts. > > So based on that I hope you understand why the equivalence lines you > have left are effectively meaningless - they are not absolute paths > and so can't match a tree to do the labelling replacement. > > Does that help make things a bit clearer on your file contexts? > > TL:DR; there was no need to "assign" as you were still using the > default mysql DB path, just a restorecon would have solved it. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >