Puppet users - Jul 2009 - File resource type: critical chmod security issue

This code:


file { ''/tmp/default'':
        ensure => directory,
        mode => ''666''
}

produces:

root@blah# ls -la /tmp/default/
total 16
drwxrwxrwx  2 root root 4096 2009-07-27 16:21 .

That is a major security issue.  I cannot recommend Puppet to my
clients if I get different results on my filesystem than from my
manifest.

Is there a consistent culture or policy in the Puppet community to
override explicit security configurations?  It must be explicitly
avoided in an audit, if that''s the case.  If there is no policy,
perhaps we should define one?

Thanks a lot!
-judd
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Judd Maltin wrote:
> This code:
>
>
> file { ''/tmp/default'':
>         ensure => directory,
>         mode => ''666''
> }
>
> produces:
>
> root@blah# ls -la /tmp/default/
> total 16
> drwxrwxrwx  2 root root 4096 2009-07-27 16:21 .
>
> That is a major security issue.  I cannot recommend Puppet to my
> clients if I get different results on my filesystem than from my
> manifest.
>
> Is there a consistent culture or policy in the Puppet community to
> override explicit security configurations?  It must be explicitly
> avoided in an audit, if that''s the case.  If there is no policy,
> perhaps we should define one?
>
> Thanks a lot!
> -judd
> >
>   
Please explain to me how this is a security risk.

-- 
Joe McDonagh
Operations Engineer
www.colonfail.com


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Judd Maltin wrote:
> This code:
>
>
> file { ''/tmp/default'':
>         ensure => directory,
>         mode => ''666''
> }
>
> produces:
>
> root@blah# ls -la /tmp/default/
> total 16
> drwxrwxrwx  2 root root 4096 2009-07-27 16:21 .
>
> That is a major security issue.  I cannot recommend Puppet to my
> clients if I get different results on my filesystem than from my
> manifest.
>
> Is there a consistent culture or policy in the Puppet community to
> override explicit security configurations?  It must be explicitly
> avoided in an audit, if that''s the case.  If there is no policy,
> perhaps we should define one?
>
> Thanks a lot!
> -judd
> >
>   
To clarify, this is like complaining umask works differently for 
directories than files.

[~/Desktop] > umask
0077
(jmcdonagh@jmcdonag) Mon Jul 27 04:48 PM /dev/pts/3
[~/Desktop] > mkdir test
(jmcdonagh@jmcdonag) Mon Jul 27 04:48 PM /dev/pts/3
[~/Desktop] > ls -ld test
drwx------ 2 jmcdonagh jmcdonagh 4096 2009-07-27 16:48 test
(jmcdonagh@jmcdonag) Mon Jul 27 04:48 PM /dev/pts/3
[~/Desktop] > touch testfile
(jmcdonagh@jmcdonag) Mon Jul 27 04:48 PM /dev/pts/3
[~/Desktop] > ls -l testfile
-rw------- 1 jmcdonagh jmcdonagh 0 2009-07-27 16:48 testfile
(jmcdonagh@jmcdonag) Mon Jul 27 04:48 PM /dev/pts/3
[~/Desktop] >

-- 
Joe McDonagh
Operations Engineer
www.colonfail.com


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi
> That is a major security issue.  I cannot recommend Puppet to my
> clients if I get different results on my filesystem than from my
> manifest.
> 
> Is there a consistent culture or policy in the Puppet community to
> override explicit security configurations?  It must be explicitly
> avoided in an audit, if that''s the case.  If there is no policy,
> perhaps we should define one?
the only existing culture is that for file resources directories
automatically get the execute bit. I don''t yet see why you''d
like to
have a directory without the execute flag set, maybe you can explain?

This "feature" is one side very helpfull if you have recursive
directories to manage, maybe you know the other side where it isn''t
that
helpfull.

Could you outline what you''d like to have in this policy. Not
explicitly
for this question you raised but more in general. Maybe it''s indeed
interesting to have one.

cheers pete

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Meier wrote:
> Could you outline what you''d like to have in this policy. Not
explicitly
> for this question you raised but more in general. Maybe it''s
indeed
> interesting to have one.
As someone who works as a security professional and has spent the
last week interacting with a small army of auditors I vote that
security policy is often a pain in the arse. :)

There are some examples of FOSS security policies:

http://www.debian.org/security/
http://www.netbsd.org/support/security/

And of course Google will show a few more up - I believe Mozilla has
one.

Generally speaking they define a few basics:

1.  Who is accountable for security
2.  What to do if you find a security issue and where to report
security issues
3.  How security patches are handled
4.  The project''s disclosure policy

Regards

James Turnbull

- --
Author of:
* Pro Linux Systems Administration
(http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet
(http://tinyurl.com/pupbook)
* Pro Nagios 2.0
(http://tinyurl.com/pronagios)
* Hardening Linux
(http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKbhjH9hTGvAxC30ARAjGMAJwKwXqm6RdMsaz9MG2vwMxL4eqBCQCgkra9
LnbnMMfBjRQeS0fE386tiko=fuo7
-----END PGP SIGNATURE-----

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi
> the only existing culture is that for file resources directories
> automatically get the execute bit. I don''t yet see why
you''d like to
> have a directory without the execute flag set, maybe you can explain?
> 
> This "feature" is one side very helpfull if you have recursive
> directories to manage, maybe you know the other side where it
isn''t that
> helpfull.
ok
http://www.wellho.net/mouth/2300_What-does-x-on-a-linux-directory-mean-.html
gave me some reasons, why you''d like to have the more strict way. I
outlined further things in the bug report:
http://projects.reductivelabs.com/issues/2451
> Could you outline what you''d like to have in this policy. Not
explicitly
> for this question you raised but more in general. Maybe it''s
indeed
> interesting to have one.
still interested.

cheers pete

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi
>> Could you outline what you''d like to have in this policy. Not
explicitly
>> for this question you raised but more in general. Maybe it''s
indeed
>> interesting to have one.
> 
> As someone who works as a security professional and has spent the
> last week interacting with a small army of auditors I vote that
> security policy is often a pain in the arse. :)
> 
> There are some examples of FOSS security policies:
> 
> http://www.debian.org/security/
> http://www.netbsd.org/support/security/
> 
> And of course Google will show a few more up - I believe Mozilla has
> one.
> 
> Generally speaking they define a few basics:
> 
> 1.  Who is accountable for security
> 2.  What to do if you find a security issue and where to report
> security issues
> 3.  How security patches are handled
> 4.  The project''s disclosure policy

ic, thought it''s going into this direction, but wasn''t sure.
thanks!

cheers pete

--~--~---------~--~----~------------~-------~--~----~
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, Jul 27, 2009 at 11:01:16PM +0200, Peter Meier
wrote:
> > Is there a consistent culture or policy in the Puppet community to
> > override explicit security configurations?  It must be explicitly
> > avoided in an audit, if that''s the case.  If there is no
policy,
> > perhaps we should define one?
> 
> the only existing culture is that for file resources directories
> automatically get the execute bit. I don''t yet see why
you''d like to
> have a directory without the execute flag set, maybe you can explain?
On a slight tangent, how about having 755 on a directory but (for
example) having 700 or 600 recursively on all the managed directories
and files underneath it (and maybe different ownership as well).  There
are valid reasons for wanting to do this but the last time I tried it, I
found it impossible with puppet.   Maybe I should look again to see what
I missed.

-- 
Bruce

I object to intellect without discipline.  I object to power without
constructive purpose. -- Spock

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Also see the bug ticket submitted:

http://projects.reductivelabs.com/issues/2451


On Jul 27, 2009, at 4:45 PM, Judd Maltin wrote:
>
> This code:
>
>
> file { ''/tmp/default'':
>        ensure => directory,
>        mode => ''666''
> }
>
> produces:
>
> root@blah# ls -la /tmp/default/
> total 16
> drwxrwxrwx  2 root root 4096 2009-07-27 16:21 .
>
> That is a major security issue.  I cannot recommend Puppet to my
> clients if I get different results on my filesystem than from my
> manifest.
>
> Is there a consistent culture or policy in the Puppet community to
> override explicit security configurations?  It must be explicitly
> avoided in an audit, if that''s the case.  If there is no policy,
> perhaps we should define one?
>
> Thanks a lot!
> -judd
> >

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

>
> Generally speaking they define a few basics:
>
> 1.  Who is accountable for security
> 2.  What to do if you find a security issue and where to report
> security issues
> 3.  How security patches are handled
> 4.  The project''s disclosure policy
>
> Regards
>
> James Turnbull

This sounds like a page for the wiki no?  Any security issues ideally  
should be reported privately first (at least with white hats).

-L

--
Larry Ludwig
Reductive Labs


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Thanks for following up on this..

There are many instances when a user will be allowed access to a
particular path, and not the containing directory''s file list.  Take a
mail server or example, where a mail system user creates directories
where users have access to their own files and folders, but not
eachothers.  It''s also good for /home directory parents so people
don''t go perusing for other users.. but they certainly can rwx their
own /home/user/*

In any case it''s VERY misleading to have an explicit command
completely ignored by an unstated policy.



On Jul 27, 5:18 pm, Peter Meier <peter.me...@immerda.ch>
wrote:
> Hi
>
>
>
> >> Could you outline what you''d like to have in this policy.
Not explicitly
> >> for this question you raised but more in general. Maybe
it''s indeed
> >> interesting to have one.
>
> > As someone who works as a security professional and has spent the
> > last week interacting with a small army of auditors I vote that
> > security policy is often a pain in the arse. :)
>
> > There are some examples of FOSS security policies:
>
> >http://www.debian.org/security/
> >http://www.netbsd.org/support/security/
>
> > And of course Google will show a few more up - I believe Mozilla has
> > one.
>
> > Generally speaking they define a few basics:
>
> > 1.  Who is accountable for security
> > 2.  What to do if you find a security issue and where to report
> > security issues
> > 3.  How security patches are handled
> > 4.  The project''s disclosure policy
>
> ic, thought it''s going into this direction, but wasn''t
sure. thanks!
>
> cheers pete
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I''m slightly confused.

- From your original example, it looks like you''re trying to create a
directory where everyone has read/write access, but nobody can traverse
the directory.

Perhaps this is the start of a symlink farm?

Most security guidance that I''ve read on the interwebs indicates that
world writable directories are fine so long as they are well documented
and they have the sticky bit set.

If I remember correctly, the reason that the ''file'' type added
the ''x''
to any directory is that the following applies to directories:

r -> I can read the file list
w -> I can write stuff to the directory
x -> I can traverse the directory

Testing a sample manifest as follows:

file { "/tmp/blah":
  ensure => "directory",
  mode => 540
}

You find:

dr-xr-x--- 2 4096 2009-07-27 22:54 /tmp/blah

So, what you''re saying is that there may be a case where I want to be
able to list the contents of a directory but not traverse it?  I''ve
only
ever once used this construct and it wasn''t very useful.

If you''re trying to keep people from reading the contents, you want:

file { "/tmp/blah":
  ensure => "directory",
  mode => 551
}

Which works properly:

dr-xr-x--x 2 4096 2009-07-27 22:54 /tmp/blah

Now, you can traverse to anything under /tmp/blah, but you can''t read
the contents of /tmp/blah, which is what you describe below.

Personally, I don''t see the default behavior as a security flaw.

The scenario that you describe below in terms of user enumeration is
easier to affect using hooks into the standard PAM libraries, though
it''s possible to protect against this as well.  At a certain point
though, you''re crippling your users'' work space.

Finally, most mail systems that I''ve used chown the mail directories to
the target user.  If this is not your experience, I would suggest taking
a look at the options behind Postfix and dovecot.  If you have an actual
mail *server* you really shouldn''t let your users onto it directly at
all.

In essence, I think that the way Puppet currently handles directories
under the file type is both sane and correct, particularly in the
recursive case.

Perhaps, I''m missing something....James?

Thanks,

Trevor

On 07/27/2009 10:47 PM, Judd wrote:
> Thanks for following up on this..
> 
> There are many instances when a user will be allowed access to a
> particular path, and not the containing directory''s file list. 
Take a
> mail server or example, where a mail system user creates directories
> where users have access to their own files and folders, but not
> eachothers.  It''s also good for /home directory parents so people
> don''t go perusing for other users.. but they certainly can rwx
their
> own /home/user/*
> 
> In any case it''s VERY misleading to have an explicit command
> completely ignored by an unstated policy.
> 
> 
> 
> On Jul 27, 5:18 pm, Peter Meier <peter.me...@immerda.ch> wrote:
>> Hi
>>
>>
>>
>>>> Could you outline what you''d like to have in this
policy. Not explicitly
>>>> for this question you raised but more in general. Maybe
it''s indeed
>>>> interesting to have one.
>>> As someone who works as a security professional and has spent the
>>> last week interacting with a small army of auditors I vote that
>>> security policy is often a pain in the arse. :)
>>> There are some examples of FOSS security policies:
>>> http://www.debian.org/security/
>>> http://www.netbsd.org/support/security/
>>> And of course Google will show a few more up - I believe Mozilla
has
>>> one.
>>> Generally speaking they define a few basics:
>>> 1.  Who is accountable for security
>>> 2.  What to do if you find a security issue and where to report
>>> security issues
>>> 3.  How security patches are handled
>>> 4.  The project''s disclosure policy
>> ic, thought it''s going into this direction, but
wasn''t sure. thanks!
>>
>> cheers pete
> > 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpuarMACgkQyjMdFR1108CYdACfaRuY5r37165GXT7A51FrDY4h
/hsAn0JZzPjG3WwPAJejtrKV37C3YCLz
=0/UX
-----END PGP SIGNATURE-----

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

2009/7/28 Judd <juddmaltin@gmail.com>:
>
> In any case it''s VERY misleading to have an explicit command
> completely ignored by an unstated policy.
>
Personally, I''m not too worried about the security aspects of this,
but I would certainly expect Puppet to do what its told.  If I fluff
my permissions, more fool me.  However if I do, for whatever reason,
want a particular mode then Puppet should respect that.

With the current operation, there''s very little flexibility.  If we
add a ''dirmode'' or something similar, as suggested by Luke in
Bug
#2451, then Puppet can handle both cases.  This seems like a no
brainer to me?

Cheers,
Bryan

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi
> On a slight tangent, how about having 755 on a directory but (for
> example) having 700 or 600 recursively on all the managed directories
> and files underneath it (and maybe different ownership as well).  There
> are valid reasons for wanting to do this but the last time I tried it, I
> found it impossible with puppet.   Maybe I should look again to see what
> I missed.
it is possible, but not that directly in one statement:

file{
   ''/a'':
     ensure => directory,
     mode => 0755;
   [ ''/a/b'', ''/a/c'' ]:
     ensure => directory,
     recurse => true
     owner => user1, mode => 0600;
   [ ''/a/d'', ''/a/e'' ]:
     ensure => directory,
     recurse => true,
     owner => user2, mode => 0600;
}

and this is exactly the case where this automatic x-bit is really  
nice. Do you envision any easier/more direct way to do it?

For sure you have to manage the content of each subdirectory  
separately as they''re managed on their own. But every other behavior  
would simply lead to a too big headache.

cheers pete

--~--~---------~--~----~------------~-------~--~----~
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 Tue, Jul 28, 2009 at 10:27:57AM +0200, Peter Meier
wrote:
> For sure you have to manage the content of each subdirectory separately 
> as they''re managed on their own.
I''m sorry, but that fails as far as I''m concerned.  I
shouldn''t be
having to specify common behaviour multiple times.

-- 
Bruce

Those who cast the votes decide nothing.  Those who count the
votes decide everything. -- Joseph Stalin

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Trevor Vaughan wrote:
> Personally, I don''t see the default behavior as a security flaw.
> 
> Perhaps, I''m missing something....James?
I tend to agree that the current behaviour meets 99% of the functional
requirements but I do understand where the original poster is coming from.

Like Luke, I don''t see why an additional attribute can''t be
added but I
don''t see it as a critical security issue.  Not to say it should not be
developed but IMHO I see the risk of a compromise through this as low
and hence feel there is a low ROI in fixing it.  If someone wants to
pony up some code and tests...

Regards

James Turnbull

-- 
Author of:
* Pro Linux Systems Administration
(http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet
(http://tinyurl.com/pupbook)
* Pro Nagios 2.0
(http://tinyurl.com/pronagios)
* Hardening Linux
(http://tinyurl.com/hardeninglinux)

Hi
>> For sure you have to manage the content of each subdirectory separately
>> as they''re managed on their own.
>
> I''m sorry, but that fails as far as I''m concerned.  I
shouldn''t be
> having to specify common behaviour multiple times.
well either your managing a resource or you''re not. Something between  
will just lead to too many problems and conflicts. or which easier way  
do you envision without having these problems?

cheers pete


--~--~---------~--~----~------------~-------~--~----~
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 Tue, Jul 28, 2009 at 10:47:07AM +0200, Peter Meier
wrote:
> 
> Hi
> 
> >> For sure you have to manage the content of each subdirectory
separately
> >> as they''re managed on their own.
> >
> > I''m sorry, but that fails as far as I''m concerned. 
I shouldn''t be
> > having to specify common behaviour multiple times.
> 
> well either your managing a resource or you''re not. Something
between
> will just lead to too many problems and conflicts. or which easier way  
> do you envision without having these problems?
> 
OK, maybe I didn''t express it clearly enough.  Puppet won''t
let me
specify one behaviour for /a and another for /a/**.  As I said, there
are valid reasons for wanting that.
-- 
Bruce

A problem shared brings the consolation that someone else is now
feeling as miserable as you.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi
> OK, maybe I didn''t express it clearly enough.  Puppet
won''t let me
> specify one behaviour for /a and another for /a/**.  As I said, there
> are valid reasons for wanting that.
I understood it that way and I also understand the reasons. My problem  
is to see a valid way to describe that within the (existing or future)  
puppet language, as well to fit it into the resource model, which  
puppet is committed to.

so something like?

file{
   ''/a:
     mode => 0755;
   "/a/**":
     mode => 0600;
}

but I''m not sure whether this wildcard resource is a good idea.

cheers pete

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

After all the Regex magic that has just ensued on the Dev list, this
should be pretty easy :-) (magic, I say!).

Having a regex match on the File type would actually be useful in a
lot of cases.  *But* it needs to be able to be sped up.

Something like forking to the native tools to do the match and perms
might work, but at least something that gets rid of the ''recursive
directory management nightmare'' where you checksum and/or record
millions of files just because you wanted to only change the
permissions.

In any case, you could then do thing like:

foo/ -> 755
foo/*.conf -> 640
foo/*.user -> 644

But, I could see ordering becoming quite important in this case.

Extremely low priority even if people do decide that it is a good idea.

Trevor

On Tue, Jul 28, 2009 at 05:47, Peter Meier<peter.meier@immerda.ch>
wrote:
>
> Hi
>
>> OK, maybe I didn''t express it clearly enough.  Puppet
won''t let me
>> specify one behaviour for /a and another for /a/**.  As I said, there
>> are valid reasons for wanting that.
>
> I understood it that way and I also understand the reasons. My problem
> is to see a valid way to describe that within the (existing or future)
> puppet language, as well to fit it into the resource model, which
> puppet is committed to.
>
> so something like?
>
> file{
>   ''/a:
>     mode => 0755;
>   "/a/**":
>     mode => 0600;
> }
>
> but I''m not sure whether this wildcard resource is a good idea.
>
> cheers pete
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---