(puppetlabs/puppet) New pull request: (#9167) Do not sent tagmail reports if no changes

(puppetlabs/puppet) Closed pull request: (#9167) Do not sent tagmail reports if no changes

Re: Re: (puppetlabs/puppet) New pull request: (#8986) Don't su when creating SSH authorized_keys

ssh_authorized_keys can be owned by anyone.

Think of how git works. The file is owned by git/gitosis/whatever, but you log in as yourself. This is the
whole point of ssh_authorized_keys and one
way that it can be abused.

In my tests, SSH doesn't care one way or the other who it's owned by so long as it's not world writable.

Trevor

On 08/30/2011 06:27 PM, Kelsey Hightower wrote:
> One use case where it may not be desirable to have users own the keys
> is in centralized ssh key setups backed by LDAP and PAM
> authentication. In this specific case all keys are stored in a central
> location such as /etc/ssh-public-keys/*.pub. The keys are only read by
> PAM (root) during the authentication phase.
> 

--

-- 
Trevor Vaughan
 Vice President, Onyx Point, Inc.
 email: tvaughan <at> onyxpoint.com
 phone: 410-541-ONYX (6699)
 pgp: 0x6C701E94

-- This account not approved for unencrypted sensitive information --

Re: Re: (puppetlabs/puppet) New pull request: (#8986) Don't su when creating SSH authorized_keys

Isn't it wonderful when you sound like a complete idiot on a public forum?

So, lesson #1 is to not post before the morning caffeine.

That said, I just re-tested this on Fedora 15 and SSH doesn't care if the authorized_keys file is owned by the
user or root. It does, however, care if
it's owned by a different user.

So, I would like to change this request to allow the key to be owned by either the user or root (which was the
purpose of my original request anyway).

Thanks!

Trevor

On 09/01/2011 05:20 AM, Trevor Vaughan wrote:
> ssh_authorized_keys can be owned by anyone.
> 
> Think of how git works. The file is owned by git/gitosis/whatever, but you log in as yourself. This is the
whole point of ssh_authorized_keys and one
> way that it can be abused.
> 
> In my tests, SSH doesn't care one way or the other who it's owned by so long as it's not world writable.
> 
> Trevor
> 
> On 08/30/2011 06:27 PM, Kelsey Hightower wrote:
>> One use case where it may not be desirable to have users own the keys
>> is in centralized ssh key setups backed by LDAP and PAM
>> authentication. In this specific case all keys are stored in a central
>> location such as /etc/ssh-public-keys/*.pub. The keys are only read by
>> PAM (root) during the authentication phase.
> 
> 

--

-- 
Trevor Vaughan
 Vice President, Onyx Point, Inc.
 email: tvaughan <at> onyxpoint.com
 phone: 410-541-ONYX (6699)
 pgp: 0x6C701E94

-- This account not approved for unencrypted sensitive information --

(puppetlabs/puppet) New pull request: Gemfile, created while trying to set up this to run on Windows

[PATCH] SELinux module headers are always little endian.

selmodule’s check of selinux module files fails on non-little endian
machines (like PPC), as it reads in the file headers using the native
byte order (selinux module headers are always in little endian).

---
 lib/puppet/provider/selmodule/semodule.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/puppet/provider/selmodule/semodule.rb b/lib/puppet/provider/selmodule/semodule.rb
index 6419715..506b8f3 100644
--- a/lib/puppet/provider/selmodule/semodule.rb
+++ b/lib/puppet/provider/selmodule/semodule.rb
 <at>  <at>  -83,7 +83,7  <at>  <at>  Puppet::Type.type(:selmodule).provide(:semodule) do
     filename = selmod_name_to_filename
     mod = File.new(filename, "r")

-    (hdr, ver, numsec) = mod.read(12).unpack('LLL')
+    (hdr, ver, numsec) = mod.read(12).unpack('VVV')

     raise Puppet::Error, "Found #{hdr} instead of magic #{magic} in #{filename}" if hdr != magic

--

-- 
1.7.6

(puppetlabs/puppet) Closed pull request: (#8413) Properly clean up stale pidfile on Windows

(puppetlabs/puppet) New pull request: (#8413) Only try to catch Process::Error if it's defined

(puppetlabs/puppet) Closed pull request: (#8413) Only try to catch Process::Error if it's defined

Re: (puppetlabs/puppet) New pull request: (#8413) Only try to catch Process::Error if it's defined

On Thu, Sep 1, 2011 at 12:00,  <wearetherobots <at> puppetlabs.com> wrote:
> Greetings!
>
> Please review the pull request #90: (#8413) Only try to catch Process::Error
> if it's defined opened by (nicklewis)
>
> Some more information about the pull request:
>
> Opened: Thu Sep 01 18:54:17 UTC 2011
> Based on: puppetlabs:2.7.x (2af580256d2b451b004f780f8b70fa3a31e37a6c)
> Requested merge: nicklewis:fix-pidlock-removal-failure
> (f7e526b86a015a63995a3300a3d438f3f3b4272f)
>
> Description:
>
> This error class is only defined when using the win32-process gem on
> Windows. So rather than always trying to rescue Process::Error (which of
> course causes its own error), we build a list of classes to rescue,
> which initially only contains Errno::ESRCH, and add Process::Error if
> it exists.
>
> Thanks!
> The Pull Request Bot
>
> Diff follows:
>
> diff --git a/lib/puppet/util/pidlock.rb b/lib/puppet/util/pidlock.rb
> index 066f66e..fcf0cf2 100644
> --- a/lib/puppet/util/pidlock.rb
> +++ b/lib/puppet/util/pidlock.rb
>  <at>  <at>  -59,9 +59,13  <at>  <at>  class Puppet::Util::Pidlock
>    def clear_if_stale
>      return if lock_pid.nil?
>
> +    errors = [Errno::ESRCH]
> +    # Process::Error can only happen, and is only defined, on Windows
> +    errors << Process::Error if defined? Process::Error
> +

Can we do that statically, rather than making the same check *every*
time we pass through this process?  A constant somewhere, built at
load time, seems like a decent trade-off to me?

Daniel
-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

--

-- 
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.