Bug #8158

Agent doesn't seem to honor manage_internal_file_permissions on $vardir due to pluginsync

Added by Joe McDonagh almost 2 years ago. Updated 6 months ago.

Status:Needs DecisionStart date:06/30/2011
Priority:NormalDue date:
Assignee:tgeeky -% Done:

0%

Category:plug-ins
Target version:-
Affected Puppet version:2.6.7 Branch:
Keywords:downloader.rb

Description

When setting this either in the config under main or agent, or running from CLI:

[/var/lib/puppet] > sudo puppet agent -t —no-manage_internal_file_permissions info: Retrieving plugin notice: /File[/var/lib/puppet/lib]/mode: mode changed ‘755’ to ‘750’ notice: /File[/var/lib/puppet/lib/facter]/mode: mode changed ‘755’ to ‘750’

This is pretty bad for me right now because devs rely on facts for all sorts of work (including revenue generation), and they rely on this running without root.

History

#1 Updated by Joe McDonagh almost 2 years ago

Appears this has to do with pluginsync. Yesterday I had finished a new deployment process for puppet, which left the puppet confdir recursively set to mod 750… It appears pluginsync isn’t smart enough to not use the mode parameter when auto generating resources for the plugins.

#2 Updated by tgeeky - almost 2 years ago

  • Status changed from Unreviewed to Accepted
  • Priority changed from High to Normal
  • deleted – totally off course here

#3 Updated by tgeeky - almost 2 years ago

  • Status changed from Accepted to Rejected
  • Assignee set to tgeeky -

Then again, with the trunk puppet, identical result.

Joe: I’m changing this bug to Rejected even though I know puppet is already doing some things wrong w.r.t octal file modelines.

I looked at your github for your manifests, but I couldn’t find any. I suggest using strings for all modelines (never bare numbers), but if you do use bare numbers, like:

:mode => 750

You must tell Ruby that this is an octal number:

:mode => 0750

I suggest just using strings:

:mode => '750'

Technically this should be correct as well:

:mode => '0750'

See [this bug] for more info.

If none of the above works as a workaround, then please re-open this bug and send me a message.

—tgeeky

#4 Updated by tgeeky - almost 2 years ago

  • Status changed from Rejected to Re-opened

#5 Updated by Joe McDonagh almost 2 years ago

So, here’s my thought: why are those resources even bothered to be generated if you set manage internal file permissions to false. In my mind it should just short circuit that whole routine of generating internal file resources etc. An admin should have the ability if they know what they’re doing to just turn this off.

#6 Updated by tgeeky - almost 2 years ago

  • Category set to plug-ins
  • Status changed from Re-opened to Accepted

More testing:

I added a line inside in

<puppet source>/puppet/lib/puppet/util/settings.rb

like

if Puppet[:manage_internal_file_permissions]
    resource[:mode] = self.mode if self.mode
    warn ("inside file_setting.rb -> to_resource() -> :manage_internal: #{path}")
  if Puppet.features.root?
    resource[:owner] = self.owner if self.owner
    resource[:group] = self.group if self.group
   end
end

and I changed the file permissions to something stupid:

root@planck:~/puppet# chown puppet:bin /var/lib/puppet/lib;chmod 700 /var/lib/puppet/lib;ls -ld /var/lib/puppet/lib
drwx------ 3 puppet bin 4096 2011-07-07 17:57 /var/lib/puppet/lib

puppet plugin download —no-manage_internal_file_permissions

notice: /File[/var/lib/puppet/lib]/owner: owner changed 'puppet' to 'root'
notice: /File[/var/lib/puppet/lib]/group: group changed 'bin' to 'root'
notice: /File[/var/lib/puppet/lib]/mode: mode changed '700' to '775'
notice: /File[/var/lib/puppet/lib/puppet]/ensure: created
notice: /File[/var/lib/puppet/lib/puppet/parser]/ensure: created
notice: /File[/var/lib/puppet/lib/puppet/parser/functions]/ensure: created
notice: /File[/var/lib/puppet/lib/puppet/parser/functions/abs.rb]/ensure: defined content as '{md5}16b8452a5066dfeacef11c8a77355220'

running without the —no-manage_internal…

root@planck:~/puppet# puppet plugin download
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/log
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/state
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/run
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/lib
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/certs
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/public_keys
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/certificate_requests
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/private_keys
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/private
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/certs/planck.d-rive.info.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/private_keys/planck.d-rive.info.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/public_keys/planck.d-rive.info.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/certs/ca.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/crl.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/facts
notice: /File[/var/lib/puppet/lib]/owner: owner changed 'puppet' to 'root'
notice: /File[/var/lib/puppet/lib]/group: group changed 'bin' to 'root'
notice: /File[/var/lib/puppet/lib]/mode: mode changed '700' to '775'
Downloaded these plugins: /var/lib/puppet/lib

I believe this post confirms that this bug has nothing to do with the manage_internal setting. Yes?

#7 Updated by tgeeky - almost 2 years ago

I clearly don’t know what i’m doing, so here’s some more debug output:

root@planck:~/puppet# puppet plugin download --debug
info: Retrieving plugin
inside downloader.rb -> file() : path -> /var/lib/puppet/lib, source -> puppet://puppet/plugins
debug: Failed to load library 'selinux' for feature 'selinux'
debug: Puppet::Type::File::ProviderMicrosoft_windows: feature microsoft_windows is missing
inside downloader.rb -> catalog() : File[/var/lib/puppet/lib]
inside downloader.rb -> file() : path -> /var/lib/puppet/lib, source -> puppet://puppet/plugins
debug: Failed to load library 'shadow' for feature 'libshadow'
debug: Failed to load library 'ldap' for feature 'ldap'
debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw yaml; using pson
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/log
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/state
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/run
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/lib
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/certs
debug: Puppet::Type::User::ProviderLdap: feature ldap is missing
debug: Puppet::Type::User::ProviderPw: file pw does not exist
debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/dscl does not exist
debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does not exist
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/public_keys
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/certificate_requests
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/private_keys
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/private
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/certs/planck.d-rive.info.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/private_keys/planck.d-rive.info.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/public_keys/planck.d-rive.info.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/certs/ca.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/crl.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/facts
debug: /File[/var/lib/puppet/log]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/run]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
debug: /File[/etc/puppet/ssl/certs]: Autorequiring File[/etc/puppet/ssl]
debug: /File[/etc/puppet/ssl]: Autorequiring File[/etc/puppet]
debug: /File[/etc/puppet/ssl/public_keys]: Autorequiring File[/etc/puppet/ssl]
debug: /File[/etc/puppet/ssl/certificate_requests]: Autorequiring File[/etc/puppet/ssl]
debug: /File[/etc/puppet/ssl/private_keys]: Autorequiring File[/etc/puppet/ssl]
debug: /File[/etc/puppet/ssl/private]: Autorequiring File[/etc/puppet/ssl]
debug: /File[/etc/puppet/ssl/certs/planck.d-rive.info.pem]: Autorequiring File[/etc/puppet/ssl/certs]
debug: /File[/etc/puppet/ssl/private_keys/planck.d-rive.info.pem]: Autorequiring File[/etc/puppet/ssl/private_keys]
debug: /File[/etc/puppet/ssl/public_keys/planck.d-rive.info.pem]: Autorequiring File[/etc/puppet/ssl/public_keys]
debug: /File[/etc/puppet/ssl/certs/ca.pem]: Autorequiring File[/etc/puppet/ssl/certs]
debug: /File[/etc/puppet/ssl/crl.pem]: Autorequiring File[/etc/puppet/ssl]
debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/puppet]
debug: Finishing transaction 92469540
notice: /File[/var/lib/puppet/lib]/owner: owner changed 'puppet' to 'root'
notice: /File[/var/lib/puppet/lib]/group: group changed 'bin' to 'root'
notice: /File[/var/lib/puppet/lib]/mode: mode changed '700' to '775'
debug: /File[/var/lib/puppet/lib]: The container /var/lib/puppet/lib will propagate my refresh event
debug: /File[/var/lib/puppet/lib]: The container /var/lib/puppet/lib will propagate my refresh event
debug: /File[/var/lib/puppet/lib]: The container /var/lib/puppet/lib will propagate my refresh event
notice: /File[/var/lib/puppet/lib/puppet]/ensure: created
debug: /File[/var/lib/puppet/lib/puppet]: The container /var/lib/puppet/lib/puppet will propagate my refresh event
debug: /var/lib/puppet/lib/puppet: The container /var/lib/puppet/lib will propagate my refresh event
debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw yaml; using pson
notice: /File[/var/lib/puppet/lib/puppet/parser]/ensure: created
debug: /File[/var/lib/puppet/lib/puppet/parser]: The container /var/lib/puppet/lib/puppet/parser will propagate my refresh event
debug: /var/lib/puppet/lib/puppet/parser: The container /var/lib/puppet/lib will propagate my refresh event
debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw yaml; using pson
notice: /File[/var/lib/puppet/lib/puppet/parser/functions]/ensure: created
debug: /File[/var/lib/puppet/lib/puppet/parser/functions]: The container /var/lib/puppet/lib/puppet/parser/functions will propagate my refresh event
debug: /var/lib/puppet/lib/puppet/parser/functions: The container /var/lib/puppet/lib will propagate my refresh event
debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw yaml; using pson
notice: /File[/var/lib/puppet/lib/puppet/parser/functions/abs.rb]/ensure: defined content as '{md5}16b8452a5066dfeacef11c8a77355220'

#8 Updated by tgeeky - almost 2 years ago

  • Status changed from Accepted to Needs Decision
  • Keywords set to downloader.rb

Aha!

I already knew the owner-group is coming from (lib/puppet/configurer/downloader.rb):

def default_arguments
  {
  :path => path,
  :recurse => true,
  :source => source,
  :tag => name,
  :owner => Process.uid,
  :group => Process.gid,
  :purge => true,
  :force => true,
  :backup => false,
  :noop => false
  }
end

But it appears the modeline is coming from the source directory of the plugins, on the server:

root@planck:/etc/puppet/modules# ls -l
total 12
drwxrwxr-x 4 puppet puppet 4096 2011-07-07 17:32 concat
drwxrwxr-x 4 puppet puppet 4096 2011-07-05 21:01 production
drwx------ 6 puppet bin    4096 2011-07-07 17:35 puppetlabs-functions

then

root@planck:/etc/puppet/modules# chown puppet:bin /var/lib/puppet/lib;chmod 000 /var/lib/puppet/lib;ls -ld /var/lib/puppet/lib
d--------- 3 puppet bin 4096 2011-07-07 18:36 /var/lib/puppet/lib

then

root@planck:/etc/puppet/modules# puppet plugin download
inside downloader.rb -> file() : path -> /var/lib/puppet/lib, source -> puppet://puppet/plugins
inside downloader.rb -> catalog() : File[/var/lib/puppet/lib]
inside downloader.rb -> file() : path -> /var/lib/puppet/lib, source -> puppet://puppet/plugins
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/log
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/state
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/run
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/lib
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/certs
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/public_keys
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/certificate_requests
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/private_keys
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/private
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/certs/planck.d-rive.info.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/private_keys/planck.d-rive.info.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/public_keys/planck.d-rive.info.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/certs/ca.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /etc/puppet/ssl/crl.pem
inside file_setting.rb -> to_resource() -> :manage_internal: /var/lib/puppet/facts
notice: /File[/var/lib/puppet/lib]/owner: owner changed 'puppet' to 'root'
notice: /File[/var/lib/puppet/lib]/group: group changed 'bin' to 'root'
notice: /File[/var/lib/puppet/lib]/mode: mode changed '0' to '700'
notice: /File[/var/lib/puppet/lib/puppet]/ensure: created
notice: /File[/var/lib/puppet/lib/puppet/parser]/ensure: created
notice: /File[/var/lib/puppet/lib/puppet/parser/functions]/ensure: created
notice: /File[/var/lib/puppet/lib/puppet/parser/functions/abs.rb]/ensure: defined content as '{md5}16b8452a5066dfeacef11c8a77355220'
Downloaded these plugins: /var/lib/puppet/lib, /var/lib/puppet/lib/puppet, /var/lib/puppet/lib/puppet/parser, /var/lib/puppet/lib/puppet/parser/functions, /var/lib/puppet/lib/puppet/parser/functions/abs.rb

then

root@planck:/etc/puppet/modules# ls -ld /var/lib/puppet/lib
drwx------ 3 root root 4096 2011-07-07 18:36 /var/lib/puppet/lib

So, this begs three questions:

  1. Joe, is your /etc/puppet/modules/ directory set to 750 somewhere?

  2. Is this mode-setting behavior a feature, a bug, or something else?

  3. Are Process.uid and Process.gid the appropriate places to be getting owner/groups?

#9 Updated by Joe McDonagh almost 2 years ago

I don’t know how much more I need to spell out on this bug. It’s pretty clear what my issue is (and yes I had already figured out this mode was coming from the source file destination, thus working around the issue by adding a permissions fix to my deploy). The problem is, this behavior of the mode should be over-ridden by the manage_internal_file_permissions setting if set to false, otherwise the option only works some of the time and it confuses people. If this is too difficult to implement or ideologically adverse to what PL has in mind, whatever, but it should be documented in the doc line for the manage_internal_file_permissions setting.

#10 Updated by Joe McDonagh almost 2 years ago

  • Subject changed from Agent doesn't seem to honor manage_internal_file_permissions to Agent doesn't seem to honor manage_internal_file_permissions on $vardir due to pluginsync

#11 Updated by Baptiste Grenier over 1 year ago

  • Target version set to 2.7.x

I am able to reproduce the same behaviour using puppet 2.7.3: the directory /var/lib/puppet/lib of my agents is chmoded to the same permissions set on the /etc/puppet/modules dir of the master. It’s a very strange and unexpected behaviour…

#12 Updated by Andrew Parker 6 months ago

  • Target version deleted (2.7.x)

Also available in: Atom PDF