selinux::module should not manage files in /usr

[vinzent]

Affected Puppet, Ruby, OS and module versions/distributions

• Module version: 0.5.1-rc0

How to reproduce (e.g Puppet code you use)

add a selinux::module resource

What are you seeing

the resource creates/manages a file in /usr/share/selinux. According FSH standard /usr is Secondary hierarchy for read-only user data;.

In /usr (excluding /usr/local) I only expect files managed by the systems package manager.

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure

What behaviour did you expect instead

The puppet managed file should be placed somewhere in /var. Maybe in some folder in puppets $vardir or whatever best practice is.

references

• Depends on BREAKING: Redesign selinux::module parameters #178 (Redesign selinux::module parameters)

[oranenj]

manifests have access to the $settings::vardir variable, which is the vardir option of the agent. For example on my desktop:
sudo puppet apply -e 'notice($settings::vardir)' results in Notice: Scope(Class[main]): /var/lib/puppet and without sudo in Notice: Scope(Class[main]): /home/oranenj/.puppet/cache

[vinzent]

$settings::vardir is the vardir of the puppet server. Not the one of the puppet client. Unfortunatly. Puppet apply behaves differently if you run as root or as user.

[oranenj]

Ah, yes, I misread the documentation... I wonder if there's a good way to get the configured vardir value somehow via Puppet's ruby API... Puppet.settings.setting('vardir').value returns nil if called straight from ruby.

[oranenj]

However, it seems to work when called in a fact during a puppet run:

require 'puppet'
Facter.add(:puppet_agent_vardir) do
  setcode do
    Puppet.settings['vardir']
  end
end

$ FACTERLIB=. sudo -E puppet apply -e'notice($::puppet_agent_vardir)'
Notice: Scope(Class[main]): /var/lib/puppet

[vinzent]

I think Puppet.settings outside of a puppet run needs to call some initialization method first.

I don't think we should rely on a client provided directory. The worst case could be that somebody sets is to "/" and we're purging "/" in the end.

[oranenj]

Well of course we shouldn't use the directory directly, but if we set it to something like $client_vardir/selinux-module-cache and validate that it's an absolute path, even in the worst case we'll just have a directory called /selinux-module-cache