Issue #5395 has been updated by James Turnbull. Status changed from Unreviewed to Needs more information
Hi Jon - our patch submission process is at: http://projects.puppetlabs.com/projects/puppet/wiki/Development_Lifecycle Thanks! ---------------------------------------- Bug #5395: ssh_authorized_key provider doesn't use the target user's gid https://projects.puppetlabs.com/issues/5395 Author: Jon Stuart Status: Needs more information Priority: Normal Assignee: Category: provider Target version: Affected Puppet version: Keywords: Branch: ### tl;dr Puppet doesn't assume the target user's `gid` when delivering a SSH key. Patch at <https://gist.github.com/653266> ### Longer We have slightly interesting user scenario where we need a user's home directory, their `.ssh` directory and `authorized_keys` to be user-owned and writeable by root, yet to be group-owned read-only by the user, like this: <pre> drwxr-x--- root manage /home/manage/ drwxr-x--- root manage /home/manage/.ssh -rw-r----- root manage /home/manage/.ssh/authorized_keys </pre> [ The motivation for this is to have a user that can not change its SSH key (the user is also `rbash`ed) for remote maintenance purposes. ] As it stands the `ssh_authorized_keys` provider can't deliver the key into this user's home because * It doesn't set the `egid` to the target user's group, thus can't even get into the home directory in the first place * It doesn't create `.ssh` with group ownership The tiny patch at <https://gist.github.com/653266> makes Puppet use the target user's group when delivering the key. The patch is against 0.25.x. I can see things have changed slightly here in 2.6 in terms of the `user` parameter to `Puppet::Util.uid` but the behaviour appears unchanged. I'll get a 2.6 patch when we upgrade. Puppet is then able to deploy the key in this situation, leaving things looking like <pre> drwxr-x--- root manage /home/manage/ drwxr-x--- manage manage /home/manage/.ssh -rw-r----- manage manage /home/manage/.ssh/authorized_keys </pre> allowing for subsequent manifest items to permission `.ssh` and `authorized_keys` per the target above. The peculiarity of this situation aside, I thinking that assuming both the `uid` and the `gid` of the target user is good from a thoroughness stance, but I'm naive about the wider context of Puppet's `SUIDManager` et al. -- 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 post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
