Puppet

I’m having a similar issue after an upgrade from puppet 0.25.0 (src/compiled) to puppet-0.25.5-1.el5 (rpm). It’s only happening to a user that has two keys. I changed the target of the second key to target a different file (authorized_keys2) and everything runs fine.

I am also getting bitten by this behavior on a 0.25.5 installation. Running puppet daemon with lots of debugging (puppetd —debug —verbose —trace —no-daemon) I get the following stack trace:

debug: Flushing ssh_authorized_key provider target /home/foo/.ssh/authorized_keys
/usr/lib/ruby/1.8/fileutils.rb:243:in `mkdir'
/usr/lib/ruby/1.8/fileutils.rb:243:in `fu_mkdir'
/usr/lib/ruby/1.8/fileutils.rb:217:in `mkdir_p'
/usr/lib/ruby/1.8/fileutils.rb:215:in `reverse_each'
/usr/lib/ruby/1.8/fileutils.rb:215:in `mkdir_p'
/usr/lib/ruby/1.8/fileutils.rb:201:in `each'
/usr/lib/ruby/1.8/fileutils.rb:201:in `mkdir_p'
/usr/lib/ruby/site_ruby/1.8/puppet/network/handler/filebucket.rb:100:in `addfile'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:145:in `withumask'
/usr/lib/ruby/site_ruby/1.8/puppet/network/handler/filebucket.rb:93:in `addfile'
/usr/lib/ruby/site_ruby/1.8/puppet/network/client/dipper.rb:29:in `backup'
/usr/lib/ruby/site_ruby/1.8/puppet/util/filetype.rb:92:in `backup'
/usr/lib/ruby/site_ruby/1.8/puppet/provider/parsedfile.rb:91:in `backup_target'
/usr/lib/ruby/site_ruby/1.8/puppet/provider/parsedfile.rb:97:in `flush_target'
/usr/lib/ruby/site_ruby/1.8/puppet/provider/parsedfile.rb:74:in `flush'
/usr/lib/ruby/site_ruby/1.8/puppet/provider/parsedfile.rb:72:in `each'
/usr/lib/ruby/site_ruby/1.8/puppet/provider/parsedfile.rb:72:in `flush'
/usr/lib/ruby/site_ruby/1.8/puppet/provider/parsedfile.rb:356:in `flush'
/usr/lib/ruby/site_ruby/1.8/puppet/provider/ssh_authorized_key/parsed.rb:72:in `flush'
/usr/lib/ruby/site_ruby/1.8/puppet/util/suidmanager.rb:59:in `asuser'
/usr/lib/ruby/site_ruby/1.8/puppet/provider/ssh_authorized_key/parsed.rb:72:in `flush'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:752:in `flush'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:94:in `apply'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:247:in `eval_children_and_apply_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:418:in `thinmark'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:417:in `thinmark'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:246:in `eval_children_and_apply_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:199:in `eval_resource'

After a bit of tracing this down it seems that it is related to lib/puppet/provider/ssh_authorized_key/parsed.rb in the flush() method interacting with the filebucket during backup. I committed what I consider at temporary fix on a private branch here of 0.25.x here:

http://github.com/hoanga/puppet/tree/bug/0.25.x/3922-ssh_authorized_key

Is there a workaround for this? I tried applying hoanga’s patch but get:

notice: //users/Account[support]/Ssh_authorized_key[support]/ensure: created
err: Could not apply complete catalog: Could not back up /home/support/.ssh/authorized_keys: Operation not permitted

Can I disable backups entirely? I tried:

File { backup => false }

but this doesn’t seem to affect Ssh_authorized_key :(

I have the same problem with puppet 2.6.1. Playing with permissions, it seem that it try to backup the authorized_keys file in /var/lib/puppet/clientbucket/… as the user specified in ssh_authorized_keys but the permissions on this directory (at least on my system) is 750 with owner root (rwxr-x—–).

If I do a chmod -R a+rwx /var/lib/puppet/clientbucket /var/lib/puppet/clientbucket/5, it run nicely. But at the end of this run, the permissions on theses directories goes back to their old values.

If i try to add a ssh key for user ‘socadm’:

ls -al /var/lib/puppet/clientbucket/5/c
total 16
drwxrwx--- 4 socadm root 4096 aoû 10 15:41 .
drwxrwx--- 6 root   root 4096 aoû  9 10:10 ..
drwxrwx--- 3 root   root 4096 aoû 10 15:41 1
drwxrwx--- 3 socadm root 4096 jui 30 15:30 e
ls -al /var/lib/puppet/clientbucket/5/c/e
total 12
drwxrwx--- 3 socadm root 4096 jui 30 15:30 .
drwxrwx--- 4 socadm root 4096 aoû 10 15:41 ..
drwxrwx--- 3 socadm root 4096 jui 30 15:30 b

It seem that the only files/directories not owned by root in clientbucket are these used by ssh_authorized_keys (checked it on a system).

This is perhaps related to commit ae520057280c2454bc44c64ac1e6686bf2eb086d.

“Write ssh_authorized_keys as user

This is a targeted fix to the issue of permissions when writing ssh authorized
key files by 1) requiring that an existing users be specified on the resource
and 2) doing the write as that user.  It's based on Michael DeHaan's initial
implementation of Luke's idea, but with a number of simplifications (mostly by
testing necessary conditions as early as possible so the code isn't cluttered
up with a lot of checks).

The tests in this version are modified slightly to remove some additional
implementation couplings that were added in master."

I am having the same issue using puppet-2.6.1-0.6.el5:

err: /Stage[main]/Auth::Users/Ssh_authorized_key[rick]: Could not evaluate: Could not back up /home/rick/.ssh/authorized_keys: Permission denied – /var/lib/puppet/clientbucket/2

Cheers,

-Rick

FWIW, I don’t think that backing up a copy of the old authrized_keys file is important… as long as maybe a diff can be shown in the output when the file is replaced… which is the same behavior that is shown when a custom fact is overwritten by pluginsync.

i think the fix is to remove the clientbucket backup of authorized_keys. i think that keeping an old public key hanging around is a security risk anyway, regardless if the file owned by the original owner of the original authorized_key file.

thoughts?

-Rick

I have the same problem with 2.6.1 and the problem here is:

there is a /etc/skel/.ssh/authorized_keys so when i create a new user: user { paul: } and he has a ssh_authroized_key { “paul@local”: } then a filebucket saves the authorized_keys, which was copied during useradd from skel, as user paul..

now creating a second user: user { pete: } with an ssh_authorized_key {} then a filebucket, using the same md5 hash (its the same empty file) tries to save the old authorized_keys as user pete but can’t save it because there is an existing one owned by paul.. if i change the content of /home/pete/.ssh/authorized_keys with something stupid like “# xxxxxxxxxxxxxxxxx” then the next puppet run works and backup the file as user pete..

so the main question for me is, is the design to backup files only on there md5 hash really a good idea? I don’t know much about the usage of filebucket but when more then one file can be saved within a md5 hash based directory (like for the one with empty files) then only one user should be used to create/update these files.. and if not more than one file can be saved within one md5 hash then especially emtpy files will be a pain when creating all the files as the origin owned user..