BREAKING: Selinux permissive type

[oranenj]

This is a rather simple provider which should fix #165.

This provider is even backwards-compatible, I think, if adding Puppet 4 types doesn't count.

There's a small corner case documented in the README where it's non-idempotent, but I didn't think it was worth complicating the parsing logic to fix.

[vinzent]

I don't think we should introduce this change to 1.0 - we don't have native types in it and thus no expirience how it will behave out there. the predecessor fryman/selinux 4mio downloads on puppet forge. I really like to introduce this in the next major version - so people already using have the clear visibility about the change.

[vinzent]

this is because semange permissive just builds a custom selinux module and loads is if you set one type permissive. if you remove it it removes the custom module - which it can't when the domain is defined permissive in the system policy.

This whole semange tool has lots of what I would call bugs or inconsitencies. :-/

[vinzent]

I think the param should default to $title if we're at it changing.

what about naming it seltype as in the other renewed types? I think this would be consistent.

[vinzent]

removing would need to happen before removing modules because one can not remove a module which has it set to permissive with semanage permissive.

[vinzent]

added backwards-incomptabile flag because the data types are not puppet3 non-future parser compatible - and that is how most users use puppet3.

[oranenj]

Something is weird with those tests I think.

I see now that it's running the context I added, but for some reason only the last bit, eg.

  on redhat-6-x86_64
    ensure selinux_permissive oddjob_mkhomedir_t is present
      should contain Selinux::Permissive[mycontextp] that comes before Anchor[selinux::end]
    ensure oddjob_mkhomedir_t is absent
      should contain Selinux::Permissive[mycontextp] that comes before Anchor[selinux::module pre]

or does that mean it does run them all but only prints out the last?

[vinzent]

I see now that it's running the context I added, but for some reason only the last bit, eg. |on redhat-6-x86_64 ensure selinux_permissive oddjob_mkhomedir_t is present should contain Selinux::Permissive[mycontextp] that comes before Anchor[selinux::end] ensure oddjob_mkhomedir_t is absent should contain Selinux::Permissive[mycontextp] that comes before Anchor[selinux::module pre] |

|no actually this should print results of all tests. i get the same result on my computer. strange. |

[vinzent]

Am 17.01.2017 um 20:52 schrieb Jarkko Oranen:

Something is weird with those tests I think. I see now that it's running the context I added, but for some reason only the last bit, eg. |on redhat-6-x86_64 ensure selinux_permissive oddjob_mkhomedir_t is present should contain Selinux::Permissive[mycontextp] that comes before Anchor[selinux::end] ensure oddjob_mkhomedir_t is absent should contain Selinux::Permissive[mycontextp] that comes before Anchor[selinux::module pre] |

I suspect that selinux__permissive is now the type and the defined type and this could confuse rspec-puppet?

[oranenj]

I suspect it has something to do with all the should expressions being inside one do block.

[vinzent]

I suspect it has something to do with all the should expressions being inside one do block.

your right. running with dedicated `it {}` works.

[oranenj]

my local rspec runs didn't give me those errors. Hm.

It's probably not kosher to reuse the let'd provider like that, but I'm not sure how to best fix it.

[oranenj]

I wonder what's causing the rspec test to fail. They work on my local machine.

Maybe it's the ruby version? Hmh

[oranenj]

Rebased and added some acceptance tests that pass on CentOS 6 at least. Still not sure if travis rspec will pass, though.

Warning: the acceptance tests are super slow because any operation with semanage seems to take ~20-30 seconds. They take about 6-7 minutes for the selinux::permissive spec

[oranenj]

nil is the bane of my existence. It's not really fun to debug these test failures given that I only seem to be able to reproduce them via travis...

[vinzent]

You could try to run the travis container locally: https://docs.travis-ci.com/user/common-build-problems/#Troubleshooting-Locally-in-a-Docker-Image Imho travis uses ubuntu as distro.

[vinzent]

tried to run with centos 5.11 :)

of course it failed. altough metadata.json states centos5 support i suspect at least selinux::module and selinux::permissive do not work at all. but this isn't related to this change.

  Info: /Stage[main]/Main/Selinux::Module[puppet_selinux_test_policy]/File[/usr/share/selinux/puppet_selinux_test_policy.te]: Scheduling refresh of Exec[/usr/share/selinux/puppet_selinux_test_policy.pp]
  Notice: /Stage[main]/Main/Selinux::Module[puppet_selinux_test_policy]/Exec[/usr/share/selinux/puppet_selinux_test_policy.pp]/returns: make: /usr/share/selinux/devel/Makefile: No such file or directory

or

      Failure/Error: shell('semanage permissive -a kernel_t')
      Beaker::Host::CommandFailure:
        Host 'centos-511-x64' exited with 1 running:
         semanage permissive -a kernel_t
        Last 10 lines of output were:
        		-M, --mask       Netmask
        		-P, --prefix     Prefix for home directory labeling
        		-L, --level      Default SELinux Level (MLS/MCS Systems only)
        		-R, --roles      SELinux Roles (ex: "sysadm_r staff_r")
        	
        		-s, --seuser     SELinux User Name
        		-t, --type       SELinux Type for the object
        		-r, --range      MLS/MCS Security Range (MLS/MCS Systems only)
        	
        	permissive not defined

[vinzent]

added issue to remove centos 5 support: #190

[oranenj]

I fixed the beaker tests, I think.

[vinzent]

successfully ran acceptance tests on centos 6, centos 7, fedora 24 and fedora 25.