Better check for which folder to relabel possible?

[sous-chefs-boneyard]

Better check for which folder to relabel possible?

[daften]

How about

find / -regextype posix-egrep -regex '/var/lib/mysql-default(/.*)?' -type d -print0  2>/dev/null | xargs -0 restorecon -iR

Or do you reckon this will get too many doubles. With find i'm worried we'll miss hidden files

[BackSlasher]

Hi @daften. I think we can modify this code to run on the actual files. Maybe something with find STUFF | xargs restorecon -R
Will you manage a PR?

[atward]

I'd like to see the code that causes it to relabel over /var/lib, it should only do that if mysql-default doesn't exist yet. Perhaps the command should actually be a lazy { }

[BackSlasher]

linked above

[atward]

To rephrase, I'd like to see the recipe that causes it to relabel over /var/lib. As per the command generator it should only do that if mysql-default does not exist. This check/command-generation is done at compile time, hence my suggestion for lazy { }

[BackSlasher]

Aha. @daften can you provide a use-case?
Also, I don't see the reason for ever running on /var/lib, but I might be missing something

[BackSlasher]

I think the issue back then was that the SELinux's regex didn't match find's regex

[atward]

Re: restorecon taking a long time. As @daften said, the relabel execute resource actually runs it twice (due to guard).

I also agree that the guard should be removed. The only caveat is this will cause the resource to always flag as being updated. To fix you would have to convert the execute to a shell_out and check length of stdout.

[BackSlasher]

Well, I think I'll accept PRs on that

[daften]

This is the regex why it falls back to /var/lib:

selinux_policy_fcontext "/var/lib/mysql-default(/.*)?" do
  secontext "mysqld_db_t"
end

It is like this because all subfolders need to get the mysql_db_t label.
What happens now is that the first parts splits on the last / it finds, so it remains with /var/lib/mysql-default( which is off course not a real folder, so it splits again on /, which gets it /var/lib.

And agreed with @atward , the guard doesn't really make sense here, since it does the same thing as the real resource execution, except simulating it instead of doing it (and in this case, it's not faster unfortunately).

I want to make a PR, but I'd like feedback on this first ;)

[atward]

Removal of guard included in #57. Also converts the command to a lazy to ensure it calculates the deepest path that exists at converge time.

[atward]

@daften, the problem is that the cookbook has no way of knowing what is the highest possible path given a regex. Take for example the following:

selinux_policy_fcontext "/var/lib/mysql-(default|dist)(/.*)?" do
  secontext "mysqld_db_t"
end

The best the code can do is check for the existence of files/directories that match the regex, and then apply to that (which it is doing by File.directory?).

If you use the lazy change from #57, and put a directory '/var/lib/mysql-default' prior to your selinux_policy_fcontext it should only run restorecon -iR /var/lib/mysql-default. I suspect you current code is installing mysql after the selinux changes.

[daften]

Nope, I get these results on all runs, not just the first that installs MySQL.
And I understand what the problem is, it can't detect the /var/lib/mysql-default as a folder, but what you're suggesting won't fix that. The folder IS already there, but because of the way it parses the regex: splitting on '/', it doesn't try to check if /var/lib/mysql-default exists, it checks if /var/lib/mysql-default( with the opening parenthesis exists. ;)

[atward]

I see it now.

Find should suit as suggested earlier, but will need to set regextype. I'm not sure if this will have compat issues (requires find 4.2.24+)

find / -regextype posix-egrep -regex '#{new_resource.file_spec}' -print0  2>/dev/null | xargs -0 restorecon -i

(will need to do shellwords/regex escape)

[BackSlasher]

RE compat, I have a supported OS list. If it passes testing, I'm happy

On Nov 14, 2016 01:06, "Adam Ward" [email protected] wrote:

I see it now.

Find should suit as suggested earlier, but will need to set regextype. I'm
not sure if this will have compat issues (requires find 4.2.24+)

find / -regextype posix-egrep -regex '#{new_resource.file_spec}' -print0 2>/dev/null | xargs -0 restorecon -i

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#56 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG3He8vpVtZiPaKXlcAvBisoXAUJkdHXks5q97QJgaJpZM4KwPRY
.

[daften]

Just checked and the find is extremely fast in both cases now (as it should be).
I'll look into a PR, but would prefer to start it when there's consensus on #57

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.