Puppet users - Nov 2010 - Default ownership for static files

Hi,

I try to serve a file

file { "/root/test3.txt":
        ensure => file,
        source => "puppet:///yum/test.txt",
}

On the puppetmaster this files look like this

#$ ls -n test.txt
-rw-r--r--  1 502  301  4  8 Nov 16:25 test.txt

Finally, here is my question: What ownership may I expect on the
resulting file ?

Actually this is the result for me:

#$ ls -l test3.txt
-rw-r--r-- 1 502 301 4 Nov  8 16:39 test3.txt

Obviously no user with uid 502 and no group with gid 301 exists on the
target system.

Interestingly other file definition results are different:

file { "/root/test1.txt":
        ensure => file,
}

file { "/root/test2.txt":
        ensure => file,
        content => "bla",
}

#$ ls -l test{1,2}.txt
-rw-r--r-- 1 root root 0 Nov  8 16:28 test1.txt
-rw-r--r-- 1 root root 3 Nov  8 16:28 test2.txt

Actually this is what I also expected for test3.txt.

-- 
Best Regards,
Markus Falb

----- "Markus Falb" <markus.falb@fasel.at> wrote:
> Hi,
> 
> I try to serve a file
> 
> file { "/root/test3.txt":
>         ensure => file,
>         source => "puppet:///yum/test.txt",
> }
> 
> On the puppetmaster this files look like this
> 
> #$ ls -n test.txt
> -rw-r--r--  1 502  301  4  8 Nov 16:25 test.txt
> 
> Finally, here is my question: What ownership may I expect on the
> resulting file ?
Do not rely on this behavior, specify the owner and mode in your file{}
resources.

That is the only reliable way.

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

On Nov 8, 2010, at 8:03 AM, R.I.Pienaar wrote:
> 
> ----- "Markus Falb" <markus.falb@fasel.at> wrote:
> 
>> Hi,
>> 
>> I try to serve a file
>> 
>> file { "/root/test3.txt":
>>        ensure => file,
>>        source => "puppet:///yum/test.txt",
>> }
>> 
>> On the puppetmaster this files look like this
>> 
>> #$ ls -n test.txt
>> -rw-r--r--  1 502  301  4  8 Nov 16:25 test.txt
>> 
>> Finally, here is my question: What ownership may I expect on the
>> resulting file ?
> 
> Do not rely on this behavior, specify the owner and mode in your file{}
resources.
> 
> That is the only reliable way.
To expand on this, one way you can rely on a default is to set the default by
putting this in site.pp (Not in any class)

File {
	mode => ''644'',
	owner => ''502'',
	group => ''301,
}

Disclaimer: I haven''t actually tested this code.

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

I am still new to the ruby language and I figured I''d share my
file_exists
function to see if it is the correct approach and to offer it out there for
people who may have the same issue. We build our vhosts based off a template
and have come across the need to add in items for specific customers in
their vhost. The problem is if you file() and the file does not exist puppet
throws an error and does not continue to run that manifest. The solution was
to add in a file_exists function to allow us to bypass that issue.


require ''puppet''

module Puppet::Parser::Functions
        newfunction(:file_exists, :type => :rvalue) do |args|
                if File.exists?(args[0])
                        return 1
                else
                        return 0
                end
        end
end


define customer::vhost($env, $url = "", $aliases = "") {
        if file_exists("customers/$name/$env/web/httpd.conf") == 1 {
                $extra = file("customers/$name/$env/web/httpd.conf")
        }
        file { "$name.conf":
                path => "/etc/httpd/conf.d/$name.conf",
                owner => root,
                group => root,
                mode => 644,
                require => Package["httpd"],
                content => template("customers/cust-vhost.erb"),
        }
}

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

Oops I guess that''ll teach me for trying to use a shortcut for
posting.

On Nov 8, 11:57 am, "Matthew Black" <mjbl...@gmail.com>
wrote:
> I am still new to the ruby language and I figured I''d share my
file_exists
> function to see if it is the correct approach and to offer it out there for
> people who may have the same issue. We build our vhosts based off a
template
> and have come across the need to add in items for specific customers in
> their vhost. The problem is if you file() and the file does not exist
puppet
> throws an error and does not continue to run that manifest. The solution
was
> to add in a file_exists function to allow us to bypass that issue.
>
> require ''puppet''
>
> module Puppet::Parser::Functions
>         newfunction(:file_exists, :type => :rvalue) do |args|
>                 if File.exists?(args[0])
>                         return 1
>                 else
>                         return 0
>                 end
>         end
> end
>
> define customer::vhost($env, $url = "", $aliases = "")
{
>         if file_exists("customers/$name/$env/web/httpd.conf") ==
1 {
>                 $extra =
file("customers/$name/$env/web/httpd.conf")
>         }
>         file { "$name.conf":
>                 path => "/etc/httpd/conf.d/$name.conf",
>                 owner => root,
>                 group => root,
>                 mode => 644,
>                 require => Package["httpd"],
>                 content =>
template("customers/cust-vhost.erb"),
>         }
>
>
>
> }- Hide quoted text -
>
> - Show quoted text -
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 08.11.10 17:03, R.I.Pienaar wrote:
> 
> ----- "Markus Falb" <markus.falb@fasel.at> wrote:
> 
>> Hi,
>>
>> I try to serve a file
>>
>> file { "/root/test3.txt":
>>         ensure => file,
>>         source => "puppet:///yum/test.txt",
>> }
>>
>> On the puppetmaster this files look like this
>>
>> #$ ls -n test.txt
>> -rw-r--r--  1 502  301  4  8 Nov 16:25 test.txt
>>
>> Finally, here is my question: What ownership may I expect on the
>> resulting file ?
> 
> Do not rely on this behavior, specify the owner and mode in your file{}
resources.
> 
> That is the only reliable way.
> 
It seems so, but do we want things this way ? I knew that I can specify
owner explicitly, instead I wanted to question the defaults.

When puppetd runs as root and without defined otherwise files should be
created with owner root in my opinion. Why should one assume that uids
on puppetmaster and client are synchronised ? Forget to define one
ownership in your manifests and possibly unrelated users on the client
can access these files unintentionally.

I think thats a security flaw. I would like to rely on reasonable
defaults. I think about opening a ticket for this.

I try in other words: A file on puppetmaster belongs to user x with uid
y and it is created on the client with uid y whatever user this
translates to. Is this intended ?

-- 
Best Regards,
Markus Falb

On Nov 8, 2010, at 9:36 AM, Markus Falb wrote:
> On 08.11.10 17:03, R.I.Pienaar wrote:
>> 
>> ----- "Markus Falb" <markus.falb@fasel.at> wrote:
>> 
>>> Hi,
>>> 
>>> I try to serve a file
>>> 
>>> file { "/root/test3.txt":
>>>        ensure => file,
>>>        source => "puppet:///yum/test.txt",
>>> }
>>> 
>>> On the puppetmaster this files look like this
>>> 
>>> #$ ls -n test.txt
>>> -rw-r--r--  1 502  301  4  8 Nov 16:25 test.txt
>>> 
>>> Finally, here is my question: What ownership may I expect on the
>>> resulting file ?
>> 
>> Do not rely on this behavior, specify the owner and mode in your file{}
resources.
>> 
>> That is the only reliable way.
>> 
> 
> It seems so, but do we want things this way ? I knew that I can specify
> owner explicitly, instead I wanted to question the defaults.
> 
> When puppetd runs as root and without defined otherwise files should be
> created with owner root in my opinion. Why should one assume that uids
> on puppetmaster and client are synchronised ? Forget to define one
> ownership in your manifests and possibly unrelated users on the client
> can access these files unintentionally.
> 
> I think thats a security flaw. I would like to rely on reasonable
> defaults. I think about opening a ticket for this.
> 
> I try in other words: A file on puppetmaster belongs to user x with uid
> y and it is created on the client with uid y whatever user this
> translates to. Is this intended ?

I''m pretty sure it was intended because I don''t think that
would happen by accident.  Someone would have needed to write the code to do
that.

Now, is it a good idea?  I con''t help you there.

If you think it''s a problem, I would consider filing a bug.

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

On 08.11.10 20:01, Patrick wrote:
> 
> On Nov 8, 2010, at 9:36 AM, Markus Falb wrote:
> 
...
>> I try in other words: A file on puppetmaster belongs to user x with uid
>> y and it is created on the client with uid y whatever user this
>> translates to. Is this intended ?
> 
> 
> I''m pretty sure it was intended because I don''t think
that would happen by accident.  Someone would have needed to write the code to
do that.
> 
> Now, is it a good idea?  I con''t help you there.
> 
> If you think it''s a problem, I would consider filing a bug.
> 
I did like you suggested
http://projects.puppetlabs.com/issues/5240

-- 
Best Regards,
Markus Falb

On Mon, Nov 8, 2010 at 8:29 AM, Patrick <kc7zzv@gmail.com> wrote:
>
> On Nov 8, 2010, at 8:03 AM, R.I.Pienaar wrote:
>
> >
> > ----- "Markus Falb" <markus.falb@fasel.at> wrote:
> >
> >> Hi,
> >>
> >> I try to serve a file
> >>
> >> file { "/root/test3.txt":
> >>        ensure => file,
> >>        source => "puppet:///yum/test.txt",
> >> }
> >>
> >> On the puppetmaster this files look like this
> >>
> >> #$ ls -n test.txt
> >> -rw-r--r--  1 502  301  4  8 Nov 16:25 test.txt
> >>
> >> Finally, here is my question: What ownership may I expect on the
> >> resulting file ?
> >
> > Do not rely on this behavior, specify the owner and mode in your
file{}
> resources.
> >
> > That is the only reliable way.
>
> To expand on this, one way you can rely on a default is to set the default
> by putting this in site.pp (Not in any class)
>
> File {
>        mode => ''644'',
>        owner => ''502'',
>        group => ''301,
> }
>
>
This would generally be a bad idea IMHO. If you put a File{} in site.pp, it
stops you from being able to put a File{} anywhere else, say in a module. If
you _do_ put a File{} in a module (which I do all the time), it disregards
the global File{} in site.pp. Same applies to any resource default.

That''s unless of course puppet has a plusignment operator for resource
types
that I wasn''t aware of.

Doug.

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

On Mon, Nov 8, 2010 at 9:36 AM, Markus Falb <markus.falb@fasel.at> wrote:
> On 08.11.10 17:03, R.I.Pienaar wrote:
> >
> > ----- "Markus Falb" <markus.falb@fasel.at> wrote:
> >
> >> Hi,
> >>
> >> I try to serve a file
> >>
> >> file { "/root/test3.txt":
> >>         ensure => file,
> >>         source => "puppet:///yum/test.txt",
> >> }
> >>
> >> On the puppetmaster this files look like this
> >>
> >> #$ ls -n test.txt
> >> -rw-r--r--  1 502  301  4  8 Nov 16:25 test.txt
> >>
> >> Finally, here is my question: What ownership may I expect on the
> >> resulting file ?
> >
> > Do not rely on this behavior, specify the owner and mode in your
file{}
> resources.
> >
> > That is the only reliable way.
> >
>
> It seems so, but do we want things this way ? I knew that I can specify
> owner explicitly, instead I wanted to question the defaults.
>
> When puppetd runs as root and without defined otherwise files should be
> created with owner root in my opinion. Why should one assume that uids
> on puppetmaster and client are synchronised ? Forget to define one
> ownership in your manifests and possibly unrelated users on the client
> can access these files unintentionally.
>
> I think thats a security flaw. I would like to rely on reasonable
> defaults. I think about opening a ticket for this.
>
> I try in other words: A file on puppetmaster belongs to user x with uid
> y and it is created on the client with uid y whatever user this
> translates to. Is this intended ?
>
>
When no owner or group is specified for the file, the default owner and
group on the target system seems to default to the same as the owner and
group on the puppetmaster, if that user exists on the target system. Ie, all
our files under /etc/puppet are owned by the puppet user, and if I
don''t
specify a use/group on a file, they end up being owned by puppet on the
target.

Doug

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

On 10.11.10 22:02, Douglas Garstang wrote:
> When no owner or group is specified for the file, the default owner and
> group on the target system seems to default to the same as the owner and
> group on the puppetmaster, if that user exists on the target system. Ie,
> all our files under /etc/puppet are owned by the puppet user, and if I
> don''t specify a use/group on a file, they end up being owned by
puppet
> on the target.
Yes, but only if the user puppet has the same uid/gid on both
puppetmaster and target and thats not a safe assumption.

-- 
Best Regards,
Markus Falb

On 11.11.10 10:44, Markus Falb wrote:
> On 10.11.10 22:02, Douglas Garstang wrote:
> 
>> When no owner or group is specified for the file, the default owner and
>> group on the target system seems to default to the same as the owner
and
>> group on the puppetmaster, if that user exists on the target system.
Ie,
>> all our files under /etc/puppet are owned by the puppet user, and if I
>> don''t specify a use/group on a file, they end up being owned
by puppet
>> on the target.
> 
> Yes, but only if the user puppet has the same uid/gid on both
> puppetmaster and target and thats not a safe assumption.
> 
And even if the uids were in sync, you cannot safely assume that the
files on puppetmaster are owned by user puppet. I dont want puppetmaster
to be able to change manifests, it needs only read access. So I run
puppetmaster as user puppet, but the files belongs to another user.
Thats convinient in another way because if the manifests-owning user has
shell access you can edit the manifests in-place (development branch
only of course ;-)

-- 
Best Regards,
Markus Falb