Issue #19005 has been updated by John Moser.
Matthaus Owens wrote:
> In this section:
> [...]
>
> You use $groups in the if and $group in the else. $group is probably undef
> here, so then the user resource wouldn't manage the groups. If you change
> that variable to $groups in both places does it behave as expected?
Good catch. I guess I was passing groups => undef, so I was asking to put the
user in only his default GID.
OK! Found the problem! If I pass groups => '', I get the following error:
Error: Failed to apply catalog: Parameter groups failed on User[dijs]:
Group names must not be empty. If you want to specify "no groups" pass
an empty array
However, if I pass groups => undef, I get no error and no changes.
If I pass groups => [ ], or a reduced number of groups, it works as expected.
So I was experiencing a different bug: Puppet fails silently to apply user
type when passed groups => undef (via literally passing 'groups => undef' or
via using a variable that hasn't been defined).
I don't know if that makes this bug "Invalid: Refile" or what. It's a
different bug, though, and of lower severity.
----------------------------------------
Bug #19005: Useradd does not remove groups when 'inclusive'
https://projects.puppetlabs.com/issues/19005#change-82362
Author: John Moser
Status: Needs More Information
Priority: High
Assignee: John Moser
Category:
Target version:
Affected Puppet version: 3.0.2
Keywords:
Branch:
This is not a duplicate of #2249
I have some such block:
user { $title:
ensure => present,
name => $name,
gid => $gid,
groups => $totalgroups,
uid => $uid,
comment => $comment,
shell => $shell,
managehome => true,
membership => inclusive, # have tried in quotes too
password => $password,
tag => 'definedusers',
}
After repeated runs, it won't remove users from groups they don't belong in.
See:
$ cat /etc/group|grep sudo
sudo:x:27:baker,charlie
$ puppet agent --test
Notice: /Stage[main]//Node[common]/Create_user_type[echo]/User[echo]/groups:
groups changed 'puppet' to
'adm,cdrom,dip,lpadmin,plugdev,puppet,sambashare,sudo'
$ cat /etc/group|grep sudo
sudo:x:27:baker,charlie,echo
Puppet has added the user to sudo. I'll remove this from Hiera.
$ vi common.yaml
...
$ puppet agent --test
$ cat /etc/group|grep sudo
sudo:x:27:baker,charlie,echo
Puppet has NOT removed the user from
$ sudo usermod -G puppet echo
$ cat /etc/group|grep sudo
sudo:x:27:baker,charlie
$ puppet agent --test
$ cat /etc/group|grep sudo
sudo:x:27:baker,charlie
However puppet has not added the user back, either. It seems that the docs say
this should not happen:
membership
Whether specified groups should be considered the complete list
(inclusive) or the minimum
list (minimum) of groups to which the user belongs. Defaults to minimum.
Valid values are
inclusive, minimum.
-- http://docs.puppetlabs.com/references/latest/type.html#user
As shown above, the membership is "inclusive".
This breaks expected security-related behavior so priority is rather high.
$ puppet --version
3.0.2
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
