Jira (PUP-7486) useradd provider silently does not set password

[Alan Smith (JIRA)]

Alan Smith updated an issue

Puppet / PUP-7486 useradd provider silently does not set password Change By: Alan Smith Summary: useradd provider silently  doesn't  does not  set password Add Comment

This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)

[Moses Mendoza (JIRA)]

Moses Mendoza commented on PUP-7486

Re: useradd provider silently does not set password H Alan Smith - thanks for filing. Yeah I'm not sure that's an optimal user experience. If you run puppet with `--debug`, you should get something like this in the output: Debug: /User[bob]: Provider useradd does not support features manages_passwords; not managing attribute password But folks probably don't run in debug by default. One difficulty is the underlying features system that puppet uses to check if a managed host has the correct attributes to manage specific properties is prolific throughout the providers.. so if we changed the default log level to warning instead of debug for these checks we'd likely heavily spam many users logs on every run. Maybe if you could opt in to making this a warning instead of debug? i.e., `puppet config set missing_features warning` Not sure. Nicholas Fagerlund thoughts?

Add Comment

[Nicholas Fagerlund (JIRA)]

Nicholas Fagerlund commented on PUP-7486

Re: useradd provider silently does not set password

Hmm. In what situation would a user set a password in a manifest and NOT actually care whether it takes effect? I can't think of any, which makes me think this should show up as a failed resource when it happens. (Drifting off-topic a bit: My instinct says if a manifest sets any parameter that the provider can't support, it ought to be an error. But there are probably a lot of cases where Puppet just silently ignores it instead. For example, I tried setting SELinux roles on a file on my Mac, and it just logged a debug message saying it was ignoring me. And there would probably be an avalanche of unintended consequences if we just universally errored on inapplicable parameters, due to assumptions from a decade of the RAL working the way it does. No idea how to approach that general problem.)

Add Comment

[Alan Smith (JIRA)]

Alan Smith commented on PUP-7486

Re: useradd provider silently does not set password

Moses Mendoza - I think under normal circumstances a user would only run puppet with `--debug` if they know something is wrong; in this case there's no indication anything is wrong. Nicholas Fagerlund - A failed resource sounds logical and entirely appropriate since the desired result could not be achieved. I have worked up this PR as a potential solution to the issue: https://github.com/puppetlabs/puppet/pull/5839

Add Comment

[Moses Mendoza (JIRA)]

Moses Mendoza commented on PUP-7486

Re: useradd provider silently does not set password

what if we issued a warning if the property is set but the prerequisites aren't met? I'm hesitant about failing the resource because its not really in line with what we do elsewhere and if that's the path i'd rather take a broader look at the behavior generically than special case useradd. But a warning (which would be printed by default) seems like it would alert folks without changing their systems.

Add Comment

[Alan Smith (JIRA)]

Alan Smith commented on PUP-7486

Re: useradd provider silently does not set password

I agree making useradd a special case is bad; if useradd is going to behave differently in a generic case, then other user providers should behave the same way in that case (i.e. password param set but unable to set password on client). I think being unable to set a password should be treated the same way a file would be treated if puppet fails to set owner/group for a path. However, unlike changing the owner/group of a file which can be done with system calls, setting a password has external dependencies (ruby-libshadow), making this a special case. Are there are other cases where an external dependency not being present can change puppet behavior on the client? If so, how is the missing dependency handled? Perhaps we should consider applying the same solution to this case, if it's been solved elsewhere.

Add Comment

[Ethan Brown (JIRA)]

Ethan Brown updated an issue

Puppet / PUP-7486

useradd provider silently does not set password

Change By: Ethan Brown Team: Agent

Add Comment

[Ethan Brown (JIRA)]

Ethan Brown updated an issue

Puppet / PUP-7486 useradd provider silently does not set password

Change By: Ethan Brown Labels: triaged

Add Comment

[Josh Cooper (JIRA)]

Josh Cooper commented on PUP-7486

Re: useradd provider silently does not set password So I can reproduce the behavior, and I'm not sure why it's happening. The way puppet is supposed to behave is that if you try to manage the password, but the provider does not support the manages_password feature, then the provider should not be suitable, so puppet should never try to use that provider and apply the resource "half-way". I would expect puppet to fail that resource, since it can't enforce the correct desired state. Note puppet supports runtime feature detection, because a user may want to install the ruby-libshadow dependency in the same run that they are trying to manage a user's password. We don't want puppet to take 2 runs to converge. That said, something is clearly not right.

Add Comment

[Alan Smith (JIRA)]

Alan Smith commented on PUP-7486

Re: useradd provider silently does not set password

Josh Cooper Are you talking about this logic for deciding if a provider supports a feature? In that code if the feature is unsupported it will log an error and return nil. All calls to `newattr` in `type.rb` (perhaps most importantly [in `[]=`|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type.rb#L670]) handle the nil case silently, that is, without error. Above the `supported_parameter?` line there is a conditional that will throw an exception, but only if the attribute is undefined for the provider, not simply unsupported. I'm not finding the code that will fail a resource if the provider doesn't support a required feature. Am I looking in the wrong place?

Add Comment

[Alan Smith (JIRA)]

Alan Smith assigned an issue to Unassigned

Puppet / PUP-7486

useradd provider silently does not set password

Change By: Alan Smith Assignee: Alan Smith

Add Comment

[Moses Mendoza (JIRA)]

Moses Mendoza assigned an issue to Josh Cooper

Puppet / PUP-7486 useradd provider silently does not set password

Change By: Moses Mendoza Assignee: Josh Cooper

Add Comment

[Geoff Nichols (JIRA)]

Geoff Nichols updated an issue

Puppet / PUP-7486 useradd provider silently does not set password

Change By: Geoff Nichols Labels: linux type_and_provider

Add Comment

This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)

[Branan Riley (JIRA)]

Branan Riley updated an issue

Puppet / PUP-7486 useradd provider silently does not set password

Change By: Branan Riley Labels: linux security triaged type_and_provider user

Add Comment

[Josh Cooper (JIRA)]

Josh Cooper commented on PUP-7486

Re: useradd provider silently does not set password Alan Smith ah my mistake, I was conflating provider features used in confine statements (which can delay evaluation of the resource until later in the run when the provider becomes suitable): confine :feature => :cfpropertylist With a provider's required_feature for managing parameter/properties. This form doesn't cause resources to be deferred: newparam(:umask, :required_feature => :umask) do I agree silently ignoring it is wrong. Either the resource should be deferred (in case libshadow is installed during the run), or the manifest author should add an explicit dependency, and puppet should fail the run if it's asked to manage a property/parameter that the provider can't.

Add Comment

[Geoff Nichols (JIRA)]

Geoff Nichols assigned an issue to Unassigned

Puppet / PUP-7486

useradd provider silently does not set password

Change By: Geoff Nichols Assignee: Josh Cooper

Add Comment

[Josh Cooper (Jira)]

Josh Cooper updated an issue

Puppet / PUP-7486 useradd provider silently does not set password

Change By: Josh Cooper Team: Night's Watch Phoenix

Add Comment

This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8)