On 23 October 2017 at 19:18, Bernard Fay <bernard.fay@xxxxxxxxx> 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@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
