(#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>
(#12463) eliminate `secure_open` in favour of `replace_file`

None of the users of `secure_open` in the codebase actually want to achieve a
result different from `replace_file`, so we might as well eliminate the older
API in favour of one that is easier to use and clearer in intent.

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Copy owner/group in replace_file

If the file doesn't exist, this will still use the current user/group as
the uid/gid of the file.
Document uid/gid-related methods in Puppet::Util
Remove unnecessary fallbacks in change_{user,group}

These methods were attempting to call change_privilege, and rescuing
NotImplementedError, to use our own implementation of similar behavior.
As it turns out, the only system on which change_privilege is not
implemented is Windows, which these methods already don't support. So
there's no reason to have a fallback that would only ever fail or not be
reached.
Prior to this commit we hard coded paths in two tests that depended on
our CI system directory structure. This made it hard to use our
acceptance suite without also including the exact same setup. It also
increased the cost of maintaining our CI setup.

This uses a path relative to the test itself (the file that it SCPs
should always be in the same directory as the test itself)

Signed-off-by: Justin Stoller <justin@puppetlabs.com>
Merge pull request #509 from justinstoller/bug/2.6.x/12692-dont_hard_code_paths_in_tests

(#12692) Don't hard code CI paths into tests
Updating CHANGELOG and lib/puppet.rb for 2.6.14
Merge tag '2.6.14' into 2.6.x
(#9491) Preserve trailing slashes in FileSettings

We use the trailing slash in a FileSetting to determine whether it's a
directory. The change in 97c043f4 caused trailing slashes to be stripped.
This caused errors like:

change from directory to file failed: Could not set 'file on ensure: Is a directory - /var/lib/puppet/facts
Revert "(#12844) Backwards compatibility for 'puppet agent --enable'"

This reverts commit fcac8f7163c99884fc6b75e3851c4a5e16a3ff07, which
was a backwards-compatibility workaround intended to handle some new
behavior related to puppet agent lockfiles that was introduced in
2.7.10.  The fix is being reverted because we've decided to remove
the new lockfile behavior from the 2.7.x series entirely, and push
it out to 3.x.
Revert "Merge remote-tracking branch 'masterzen/tickets/2.7.x/3757' into 2.7.x"

This reverts commit 86a806f595f8b7bb280c8c445eef51dfd71bf39d, reversing
changes made to ac81771a9cc70b5fb58f86439ebb0585ce92d4e8.

See tickets #3757, #12844, #4836, #11057.  These changes were deemed to
be breaking public APIs, and thus are being reverted from 2.7.x.  They'll
be reintroduced in 3.x.

(The changes in question were relating to how puppet agent creates /
manages its lockfiles.)

Conflicts:

	lib/puppet/util/pidlock.rb
	spec/unit/agent_spec.rb
	spec/unit/util/pidlock_spec.rb
(#10722) Display errors on HTTP report submission failures

We were failing silently if the report submission to http
returned a non-200 response code.
(#12844) Agent lockfiles: backwards compatibility with 2.7.10/2.7.11

In 2.7.10 there was a change in behavior introduced with regards
to agent lockfiles.  Basically we split the concept of "an agent
is currently running" apart from the concept of "the agent has
been administratively disabled" by using 2 different lockfiles.

That change was determined to have broken compatibility with
mcollective, so it has been reverted as of 2.7.12.

This commit provides backwards compatibility between 2.7.12+
and 2.7.10/2.7.11 for cases where a user may have administratively
disabled their agent and then upgraded to a newer version of puppet.
(#12933) Better error message when agent is administratively disabled

Detect the difference between the cases where an agent run is
aborted due to another agent run already in progress vs. being
aborted due to the agent being administratively disabled via
'--disable', and print a more useful message for the latter case.