(#10739) Provide default subjectAltNames while bootstrapping master

Prior to #2848 (CVE-2011-3872), if Puppet[:certdnsnames] was not set,
puppet would add default subjectAltNames to any non-CA cert it signed,
including agent certs. The subjectAltNames were of the form:

  DNS:puppet, DNS:<fqdn>, DNS:puppet.<domain>

The fix for #2848, prevented subjectAltNames from ever being
implicitly added at signing time. But during this change, the default
subjectAltNames behavior was accidentally removed.

This commit restores the 'defaulting' behavior that existed
previously, but only when bootstrapping the initial master.
Additionally, default subjectAltNames are only ever added when
generating the master's certificate signing request, not at signing
time. This is important, because it ensures all subjectAltNames
originate from the CSR and are subject to our internal signing policy.

The code now requires that all of the following be true in order to
add default subjectAltNames to the CSR:

 1. We are a CA and master
 2. We're signing the master's cert, not self-signing the CA
 3. The CSR is for the current host
 4. No subjectAltNames have been specified, e.g. Puppet[:dns_alt_names]
 5. The master can resolve its fqdn

These should only ever be true when bootstrapping the initial
master. In particular, it should never be true for the CA's
self-signed cert, for remote agents, or for servers that are either
masters or CAs, but not both.

The fqdn requirement existed previously, and so the same behavior has
been restored.

Note if Puppet[:dns_alt_names] are specified when bootstrapping the
master, then we do not merge the default options -- it's either one of
the other, but not both.
Merge pull request #238 from joshcooper/2.6.x

(#10739) Provide default subjectAltNames while bootstrapping master
Updating CHANGELOG for 2.6.13rc1
Updated CHANGELOG for 2.6.13
(#11764) Fix cron jobs for passing block to method

Fixing the run_x_on methods to accept a passed block causes the
cron resrouce tests to fail.  Minor fixes to regex and asserts
fix the issue.

This affect all versions of puppet and should be merged up.
Merge pull request #307 from djm68/11764_fix_cron_tests

(#11764) Fix cron jobs for passing block to method
(#11764) Fix failing cron test

Small logic error is one cron tests -- assert in wrong
step.  Fixed and tested.
Merge branch '11764_fix_cron_tests_x2' of https://github.com/djm68/puppet into 2.6.x

* '11764_fix_cron_tests_x2' of https://github.com/djm68/puppet:
  (#11764) Fix failing cron test
(#5246) Puppetd does not remove it's pidfile when it exits

The Puppet::Daemon instance sets up the pid file when it starts
but it's up to the user of that object to arrange for stop to be
called

There are signal handlers setup to call stop but in a onetime run
those are never called

This change arrange for the stop method to be called after a onetime
run is done but do not hand the task of exiting the application over
to that so that the agent application can handle the report status
based exit codes
Merge pull request #327 from ripienaar/bug/2.6.x/5246

(#5246) Puppetd does not remove it's pidfile when it exits
(#11996) Fix test failures due to hash processing order changes.

As part of fixing CVE-2011-4815, Ruby has made the order that hash tables are
keyed unpredictable - where they were formerly fixed in stone.  This, in turn,
means that all the tests that depended on that order started to fail randomly
on the most recent patch release of Ruby 1.8.7, and will fail in recent Ruby
1.9.* releases.

This makes those tests insensitive to ordering of the content, at the cost of
being a little less strict in places.  This seems less harmful, overall, than
alternative approaches like sorting the hash in the code, or enumerating all
possible combinations of order and testing on all of them.

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Merge pull request #342 from daniel-pittman/refactor/2.6.x/11996-spec-failures-after-ruby-187-p357

(#11996) Fix test failures due to hash processing order changes.
(#6541) Use the same filebucket for backup and restore

The acceptance test for #6541 was using `puppet filebucket backup -l
/dev/null` to cause a 0-length file to be created in the agent's
filebucket, and then attempting to retrieve the file using:

    file { ...:
      content => '{md5}d41d8cd98f00b204e9800998ecf8427e'

However, this was failing because the former was writing to
`${vardir}/bucket`, while the latter was trying to read from
`${vardir}/clientbucket`, and failing to find the 0-length file.

This test reported a false positive earlier, because the test was
reusing the clientbucket from a previous test. Now that the acceptance
tests clean the agent vardir, it uncovered this problem.

This commit changes the test to create a 0-length file, then
overwrites it, causing the old file to be backed up into the
clientbucket.
Merge pull request #395 from joshcooper/ticket/2.6.x/6541-use-the-same-filebucket

(#6541) Use the same filebucket for backup and restore
(#12457) add users primary group, not Process.gid, in initgroups

The Process.gid (real gid) was always included when initialising supplementary
groups in the initgroups method (called when changing the euid via the
change_user method).  This has been replaced by the primary gid of the user.

This led to a privilege leak, as well as a potential surprise when it came to
file ownership, in both the agent and the master.

Fix and analysis by Dominic Cleal <dcleal@redhat.com>

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
(#12458) default to users primary group, not root, in `asuser`

When only a user (no group) was given to the asuser method, the egid wouldn't
be changed and would remain the privileged gid.  This has been changed to the
primary gid of the user.

Fix and analysis by Dominic Cleal <dcleal@redhat.com>

Contributed: Daniel Pittman <daniel@puppetlabs.com>
Contributed: Deepak Giridharagopal <deepak@puppetlabs.com>
Contributed: Nick Lewis <nick@puppetlabs.com>
(#12459) drop supplementary groups when permanently dropping UID

On certain platforms, Process::UID.change_privilege doesn't handle
changing supplementary groups. In that case, we need to always
explicitly initgroups, regardless of whether we're using
change_privilege, or change_group/change_user.

Analysis by Dominic Cleal <dcleal@redhat.com>

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
(#12463) add secure `replace_file` to Puppet::Util

There is some complex logic around replacing an existing file safely, and it
used to be scattered all over the tree - making the whole system much harder
to use nicely and pleasantly.

It is much better that we provide a central, and easy to use, method for
achieving that specific and common goal in a consistent, secure, and easy to
audit fashion.

Based on code submitted by me on 2010-04-08.

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
(#12462) user_role_add: use `replace_file` for /etc/shadow

The user_role_add provider for user management previously open-coded the safe,
atomic replacement of /etc/shadow after in modified it.

Mostly even safely, except that it didn't enforce permissions on the temporary
file, so might have spilled data to third parties, if tempfile isn't
sufficiently secure.  (Ruby makes no promises about tempfile mode.)

We replace that with the standard, central replace_file API, which ensures
that is done in a safe, correct, and standard fashion.

On the way through this removes the window where this could previously have
lost the content of /etc/shadow due to an unfortunately timed crash, by
ensuring we fsync the content of the temporary file.

It also documents, but doesn't eliminate, the lack of locking and other races
around this update to the shadow file.

Finally, some minor code and test updates to make it easier to test this on
fake data, rather than like on your own /etc/shadow file...

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
(#12460) use `replace_file` for the .k5login file

Previously this hand-coded replacing the .k5login file; Replacing that with
the standard API ensures consistent, safe, and atomic updates of the target
file.

It also reduces the cognitive burden of the provider, since the semantics of
the standard method are clearer than the semantics of the type.

Finally, this commit adds some tests for the type, and the inline provider, to
help ensure that the type continues to work into the future.

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>