summaryrefslogtreecommitdiffstats
path: root/lib/puppet/rails/rails_resource.rb
diff options
context:
space:
mode:
authorNick Lewis <nick@puppetlabs.com>2011-08-09 17:48:33 -0700
committerNick Lewis <nick@puppetlabs.com>2011-08-11 17:05:21 -0700
commit2a0de12af5305ed54dd99391ee17533e71e0d88e (patch)
tree67582ead79e6d3a19d39d1b5b1dd2a3ecc86caaa /lib/puppet/rails/rails_resource.rb
parent00c4b25010068eeb57a15104fb178a72af733fda (diff)
downloadpuppet-2a0de12af5305ed54dd99391ee17533e71e0d88e.tar.gz
puppet-2a0de12af5305ed54dd99391ee17533e71e0d88e.tar.xz
puppet-2a0de12af5305ed54dd99391ee17533e71e0d88e.zip
(#8770) Always fully drop privileges when changing user
On Mac OS X, it is only possible to directly change the euid of a process, and not the uid. Thus, when a puppet master started as root on OS X would change to the service user (puppet), it would leave the uid of its process set to 0. This allowed any type of Ruby plugin executed on the master (a type, provider, function, etc.) to trivially regain root privileges (by setting the euid of its process back to 0) and potentially compromise the master. Now, when permanently changing user, we will first try Process::UID.change_privilege, before falling back to setting the euid/uid ourselves. change_privilege correctly sets the uid of the process to the desired new uid, preventing the process from later escalating itself back to root. Similar behavior is also used when changing group. This has no effect on the behavior when temporarily changing user/group (for instance, to execute a single command or create a file as a particular user). Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>
Diffstat (limited to 'lib/puppet/rails/rails_resource.rb')
0 files changed, 0 insertions, 0 deletions