Puppet

I would love to see this fixed. I really want to use symlinks for my puppet.conf file. The manage_internal_file_permissions option only applies to file mode and ownership. It does not prevent puppet from trying to remove a symlink’d puppet.conf.

Earlier discussions of this and similar issues seemed to stall on security concerns, though I’m not at the moment recalling the details. In any case, we certainly haven’t moved on it in the two+ years since it was accepted.

We should probably either do it or document the reason we are not doing it rather than leaving it in accepted but never acted on limbo.

In the absence of any concrete reason to not allow symlinks, I suggest we extend ‘manage_internal_file_permissions = false’ to not replace symlinks.

Even allowing that the name of the option would then be somewhat misleading, I really don’t think it warrants yet another option.

I’ll take ownership of this while trying to track down any info about potential security issues that has come up before.

so that search was faster than I expected. I can’t see how a symlink race condition could be a problem in this situation given the perms on /etc/puppet itself.

Not targeted to a specific release yet.

This is a big usability problem in my opinion. We’ve had regular IRC visitors complaining about this. Targeting to statler.

Nigel Kersten wrote:

We’ve definitely decided to fix this.

It is a change in behavior that we’re not going to push in 2.6.x however.

Given that the proposed fix looks to be minimal, not intrusive and provide significant benefit, this is getting targeted at 2.6.x as well.

Merged to 2.6.x in commit:e62734c661b660f6b8620da28589da7c6472808e.

Puppet will now set links => follow on file resources creating by settings, rather than links => manage. The behavior of these symlinks is the same as any other file resource. That is, if the target of the symlink doesn’t exist, Puppet will consider this an error. Similarly, if the target of the symlink is a file, then the symlink will still be replaced with a directory, rather than replacing its target.