Template resource: default value for mode attribute?


#1

It appears that if one does not specify a mode,
files generated/overwritten by template resources
end up having permissions like -rw------- (0600).

This seems like a sane default. But maybe the
documentation should make this explicit.
Right now, the template resource wiki page
http://wiki.opscode.com/display/chef/Resources#Resources-Template
reads:

Attribute: mode
Description: "The octal mode of the file - 0755"
Default Value: (nothing here)

Take for example the simple case of managing /etc/hosts.
This file usually has permissions -rw-r–r--.

template '/etc/hosts’
source 'hosts.erb’
end

… will overwrite /etc/hosts as expected, but if one
forgets to pass in the mode attribute, '/etc/hosts’
ends up as readable only by root (i.e., -rw-------).

This is not really a major problem (I simply make sure
to pass in a mode explicitly).
but as a suggestion:

(1) For existing files that get ‘templated’,
chef-client could just leave the permissions untouched.

OR

(2) Fix the docs to make it very clear that unless
one specifies a mode explicitly, the file
created/overwritten by the template will end up
with the default mode (and that the default
mode is 0600, not 0755)

For the record, I’m still running 0.9.16.

Thanks,
Faiz


#2

I verified this and I’ve updated the Template entry on the Resources
page to reflect the default.
http://wiki.opscode.com/display/chef/Resources#Resources-Template

Thanks,
Matt Ray
Senior Technical Evangelist | Opscode Inc.
matt@opscode.com | (512) 731-2218
Twitter, IRC, GitHub: mattray

On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi faiz@dreamarts.co.jp wrote:

It appears that if one does not specify a mode,
files generated/overwritten by template resources
end up having permissions like -rw------- (0600).

This seems like a sane default. But maybe the
documentation should make this explicit.
Right now, the template resource wiki page
http://wiki.opscode.com/display/chef/Resources#Resources-Template
reads:

Attribute: mode
Description: "The octal mode of the file - 0755"
Default Value: (nothing here)

Take for example the simple case of managing /etc/hosts.
This file usually has permissions -rw-r–r--.

template '/etc/hosts’
source 'hosts.erb’
end

… will overwrite /etc/hosts as expected, but if one
forgets to pass in the mode attribute, '/etc/hosts’
ends up as readable only by root (i.e., -rw-------).

This is not really a major problem (I simply make sure
to pass in a mode explicitly).
but as a suggestion:

(1) For existing files that get ‘templated’,
chef-client could just leave the permissions untouched.

OR

(2) Fix the docs to make it very clear that unless
one specifies a mode explicitly, the file
created/overwritten by the template will end up
with the default mode (and that the default
mode is 0600, not 0755)

For the record, I’m still running 0.9.16.

Thanks,
Faiz


#3

This is not always the default - it’s going to be a reflection of the
user who runs chef’s umask. Most operating systems will have this be
0600, but not all of them will - so you can’t rely on it as a general
rule.

Adam

On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray matt@opscode.com wrote:

I verified this and I’ve updated the Template entry on the Resources
page to reflect the default.
http://wiki.opscode.com/display/chef/Resources#Resources-Template

Thanks,
Matt Ray
Senior Technical Evangelist | Opscode Inc.
matt@opscode.com | (512) 731-2218
Twitter, IRC, GitHub: mattray

On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi faiz@dreamarts.co.jp wrote:

It appears that if one does not specify a mode,
files generated/overwritten by template resources
end up having permissions like -rw------- (0600).

This seems like a sane default. But maybe the
documentation should make this explicit.
Right now, the template resource wiki page
http://wiki.opscode.com/display/chef/Resources#Resources-Template
reads:

Attribute: mode
Description: "The octal mode of the file - 0755"
Default Value: (nothing here)

Take for example the simple case of managing /etc/hosts.
This file usually has permissions -rw-r–r--.

template '/etc/hosts’
source 'hosts.erb’
end

… will overwrite /etc/hosts as expected, but if one
forgets to pass in the mode attribute, '/etc/hosts’
ends up as readable only by root (i.e., -rw-------).

This is not really a major problem (I simply make sure
to pass in a mode explicitly).
but as a suggestion:

(1) For existing files that get ‘templated’,
chef-client could just leave the permissions untouched.

OR

(2) Fix the docs to make it very clear that unless
one specifies a mode explicitly, the file
created/overwritten by the template will end up
with the default mode (and that the default
mode is 0600, not 0755)

For the record, I’m still running 0.9.16.

Thanks,
Faiz


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#4

Reverted my edit then. Does this behavior go for File, Template,
Remote_File and Cookbook_File? If so should we note it in File
Distribution page?
http://wiki.opscode.com/display/chef/File+Distribution#FileDistribution-FileSpecificity

Thanks,
Matt Ray
Senior Technical Evangelist | Opscode Inc.
matt@opscode.com | (512) 731-2218
Twitter, IRC, GitHub: mattray

On Fri, Jun 3, 2011 at 2:27 PM, Adam Jacob adam@opscode.com wrote:

This is not always the default - it’s going to be a reflection of the
user who runs chef’s umask. Most operating systems will have this be
0600, but not all of them will - so you can’t rely on it as a general
rule.

Adam

On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray matt@opscode.com wrote:

I verified this and I’ve updated the Template entry on the Resources
page to reflect the default.
http://wiki.opscode.com/display/chef/Resources#Resources-Template

Thanks,
Matt Ray
Senior Technical Evangelist | Opscode Inc.
matt@opscode.com | (512) 731-2218
Twitter, IRC, GitHub: mattray

On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi faiz@dreamarts.co.jp wrote:

It appears that if one does not specify a mode,
files generated/overwritten by template resources
end up having permissions like -rw------- (0600).

This seems like a sane default. But maybe the
documentation should make this explicit.
Right now, the template resource wiki page
http://wiki.opscode.com/display/chef/Resources#Resources-Template
reads:

Attribute: mode
Description: "The octal mode of the file - 0755"
Default Value: (nothing here)

Take for example the simple case of managing /etc/hosts.
This file usually has permissions -rw-r–r--.

template '/etc/hosts’
source 'hosts.erb’
end

… will overwrite /etc/hosts as expected, but if one
forgets to pass in the mode attribute, '/etc/hosts’
ends up as readable only by root (i.e., -rw-------).

This is not really a major problem (I simply make sure
to pass in a mode explicitly).
but as a suggestion:

(1) For existing files that get ‘templated’,
chef-client could just leave the permissions untouched.

OR

(2) Fix the docs to make it very clear that unless
one specifies a mode explicitly, the file
created/overwritten by the template will end up
with the default mode (and that the default
mode is 0600, not 0755)

For the record, I’m still running 0.9.16.

Thanks,
Faiz


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#5

It’s true anything that writes a file.

Adam

On Fri, Jun 3, 2011 at 2:19 PM, Matt Ray matt@opscode.com wrote:

Reverted my edit then. Does this behavior go for File, Template,
Remote_File and Cookbook_File? If so should we note it in File
Distribution page?
http://wiki.opscode.com/display/chef/File+Distribution#FileDistribution-FileSpecificity

Thanks,
Matt Ray
Senior Technical Evangelist | Opscode Inc.
matt@opscode.com | (512) 731-2218
Twitter, IRC, GitHub: mattray

On Fri, Jun 3, 2011 at 2:27 PM, Adam Jacob adam@opscode.com wrote:

This is not always the default - it’s going to be a reflection of the
user who runs chef’s umask. Most operating systems will have this be
0600, but not all of them will - so you can’t rely on it as a general
rule.

Adam

On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray matt@opscode.com wrote:

I verified this and I’ve updated the Template entry on the Resources
page to reflect the default.
http://wiki.opscode.com/display/chef/Resources#Resources-Template

Thanks,
Matt Ray
Senior Technical Evangelist | Opscode Inc.
matt@opscode.com | (512) 731-2218
Twitter, IRC, GitHub: mattray

On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi faiz@dreamarts.co.jp wrote:

It appears that if one does not specify a mode,
files generated/overwritten by template resources
end up having permissions like -rw------- (0600).

This seems like a sane default. But maybe the
documentation should make this explicit.
Right now, the template resource wiki page
http://wiki.opscode.com/display/chef/Resources#Resources-Template
reads:

Attribute: mode
Description: "The octal mode of the file - 0755"
Default Value: (nothing here)

Take for example the simple case of managing /etc/hosts.
This file usually has permissions -rw-r–r--.

template '/etc/hosts’
source 'hosts.erb’
end

… will overwrite /etc/hosts as expected, but if one
forgets to pass in the mode attribute, '/etc/hosts’
ends up as readable only by root (i.e., -rw-------).

This is not really a major problem (I simply make sure
to pass in a mode explicitly).
but as a suggestion:

(1) For existing files that get ‘templated’,
chef-client could just leave the permissions untouched.

OR

(2) Fix the docs to make it very clear that unless
one specifies a mode explicitly, the file
created/overwritten by the template will end up
with the default mode (and that the default
mode is 0600, not 0755)

For the record, I’m still running 0.9.16.

Thanks,
Faiz


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#6

Ah, I see.

What about suggestion (1), though? I think it might
be a less of a surprise to users if the effect
of applying a template resource respected the original
mode of the file (in the absence of a mode attribute).

If requesting such a change in behavior is not an
option, it would still be useful for the wiki to
explicitly mention the umask defaults that apply
in the absence of a mode.

(I’m happy to do the wiki edit if it’s too much of a bother)

Faiz

On Fri, 3 Jun 2011 12:27:16 -0700
Adam Jacob adam@opscode.com wrote:

This is not always the default - it’s going to be a reflection of the
user who runs chef’s umask. Most operating systems will have this be
0600, but not all of them will - so you can’t rely on it as a general
rule.

Adam

On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray matt@opscode.com wrote:

I verified this and I’ve updated the Template entry on the Resources
page to reflect the default.
http://wiki.opscode.com/display/chef/Resources#Resources-Template

Thanks,
Matt Ray
Senior Technical Evangelist | Opscode Inc.
matt@opscode.com | (512) 731-2218
Twitter, IRC, GitHub: mattray

On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi faiz@dreamarts.co.jp
wrote:

It appears that if one does not specify a mode,
files generated/overwritten by template resources
end up having permissions like -rw------- (0600).

This seems like a sane default. But maybe the
documentation should make this explicit.
Right now, the template resource wiki page
http://wiki.opscode.com/display/chef/Resources#Resources-Template
reads:

Attribute: mode
Description: "The octal mode of the file - 0755"
Default Value: (nothing here)

Take for example the simple case of managing /etc/hosts.
This file usually has permissions -rw-r–r--.

template '/etc/hosts’
source 'hosts.erb’
end

… will overwrite /etc/hosts as expected, but if one
forgets to pass in the mode attribute, '/etc/hosts’
ends up as readable only by root (i.e., -rw-------).

This is not really a major problem (I simply make sure
to pass in a mode explicitly).
but as a suggestion:

(1) For existing files that get ‘templated’,
chef-client could just leave the permissions untouched.

OR

(2) Fix the docs to make it very clear that unless
one specifies a mode explicitly, the file
created/overwritten by the template will end up
with the default mode (and that the default
mode is 0600, not 0755)

For the record, I’m still running 0.9.16.

Thanks,
Faiz


#7

That may be more confusing since many SCMs don’t track file mode. Then there
are different OSes with different schemes.

Sent from WOPR
On Jun 5, 2011 2:45 AM, “Faiz Kazi” faiz@dreamarts.co.jp wrote:

Ah, I see.

What about suggestion (1), though? I think it might
be a less of a surprise to users if the effect
of applying a template resource respected the original
mode of the file (in the absence of a mode attribute).

If requesting such a change in behavior is not an
option, it would still be useful for the wiki to
explicitly mention the umask defaults that apply
in the absence of a mode.

(I’m happy to do the wiki edit if it’s too much of a bother)

Faiz

On Fri, 3 Jun 2011 12:27:16 -0700
Adam Jacob adam@opscode.com wrote:

This is not always the default - it’s going to be a reflection of the
user who runs chef’s umask. Most operating systems will have this be
0600, but not all of them will - so you can’t rely on it as a general
rule.

Adam

On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray matt@opscode.com wrote:

I verified this and I’ve updated the Template entry on the Resources
page to reflect the default.
http://wiki.opscode.com/display/chef/Resources#Resources-Template

Thanks,
Matt Ray
Senior Technical Evangelist | Opscode Inc.
matt@opscode.com | (512) 731-2218
Twitter, IRC, GitHub: mattray

On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi faiz@dreamarts.co.jp
wrote:

It appears that if one does not specify a mode,
files generated/overwritten by template resources
end up having permissions like -rw------- (0600).

This seems like a sane default. But maybe the
documentation should make this explicit.
Right now, the template resource wiki page
http://wiki.opscode.com/display/chef/Resources#Resources-Template
reads:

Attribute: mode
Description: "The octal mode of the file - 0755"
Default Value: (nothing here)

Take for example the simple case of managing /etc/hosts.
This file usually has permissions -rw-r–r--.

template '/etc/hosts’
source 'hosts.erb’
end

… will overwrite /etc/hosts as expected, but if one
forgets to pass in the mode attribute, '/etc/hosts’
ends up as readable only by root (i.e., -rw-------).

This is not really a major problem (I simply make sure
to pass in a mode explicitly).
but as a suggestion:

(1) For existing files that get ‘templated’,
chef-client could just leave the permissions untouched.

OR

(2) Fix the docs to make it very clear that unless
one specifies a mode explicitly, the file
created/overwritten by the template will end up
with the default mode (and that the default
mode is 0600, not 0755)

For the record, I’m still running 0.9.16.

Thanks,
Faiz


#8

Yeah - if you don’t specify a mode, we shouldn’t be modifying it -
that’s definitely a bug, if we’re behaving that way.

Adam

On Sat, Jun 4, 2011 at 11:44 PM, Faiz Kazi faiz@dreamarts.co.jp wrote:

Ah, I see.

What about suggestion (1), though? I think it might
be a less of a surprise to users if the effect
of applying a template resource respected the original
mode of the file (in the absence of a mode attribute).

If requesting such a change in behavior is not an
option, it would still be useful for the wiki to
explicitly mention the umask defaults that apply
in the absence of a mode.

(I’m happy to do the wiki edit if it’s too much of a bother)

Faiz

On Fri, 3 Jun 2011 12:27:16 -0700
Adam Jacob adam@opscode.com wrote:

This is not always the default - it’s going to be a reflection of the
user who runs chef’s umask. Most operating systems will have this be
0600, but not all of them will - so you can’t rely on it as a general
rule.

Adam

On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray matt@opscode.com wrote:

I verified this and I’ve updated the Template entry on the Resources
page to reflect the default.
http://wiki.opscode.com/display/chef/Resources#Resources-Template

Thanks,
Matt Ray
Senior Technical Evangelist | Opscode Inc.
matt@opscode.com | (512) 731-2218
Twitter, IRC, GitHub: mattray

On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi faiz@dreamarts.co.jp
wrote:

It appears that if one does not specify a mode,
files generated/overwritten by template resources
end up having permissions like -rw------- (0600).

This seems like a sane default. But maybe the
documentation should make this explicit.
Right now, the template resource wiki page
http://wiki.opscode.com/display/chef/Resources#Resources-Template
reads:

Attribute: mode
Description: "The octal mode of the file - 0755"
Default Value: (nothing here)

Take for example the simple case of managing /etc/hosts.
This file usually has permissions -rw-r–r--.

template '/etc/hosts’
source 'hosts.erb’
end

… will overwrite /etc/hosts as expected, but if one
forgets to pass in the mode attribute, '/etc/hosts’
ends up as readable only by root (i.e., -rw-------).

This is not really a major problem (I simply make sure
to pass in a mode explicitly).
but as a suggestion:

(1) For existing files that get ‘templated’,
chef-client could just leave the permissions untouched.

OR

(2) Fix the docs to make it very clear that unless
one specifies a mode explicitly, the file
created/overwritten by the template will end up
with the default mode (and that the default
mode is 0600, not 0755)

For the record, I’m still running 0.9.16.

Thanks,
Faiz


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#9

On Sun, 5 Jun 2011 10:02:33 -0700
Adam Jacob adam@opscode.com wrote:

Here’s an ad-hoc patch we use locally to address this problem
(shown against v0.10).

Basically, mv was being used to move the rendered template
to the resulting file. This has at least the following drawbacks:

  1. mv may preserve mode/ownership, but the mode/ownership of
    the rendered template is not based on that of the original file.
    This means in the absence of an explicit mode, the file
    ends up with it’s original mode modified (hence the bug)
  2. SELinux - mv is trickier than cp.
    http://www.centos.org/docs/5/html/Deployment_Guide-en-US/rhlcommon-chapter-0017.html

Faiz

Yeah - if you don’t specify a mode, we shouldn’t be modifying it -
that’s definitely a bug, if we’re behaving that way.

Adam

On Sat, Jun 4, 2011 at 11:44 PM, Faiz Kazi faiz@dreamarts.co.jp
wrote:

Ah, I see.

What about suggestion (1), though? I think it might
be a less of a surprise to users if the effect
of applying a template resource respected the original
mode of the file (in the absence of a mode attribute).

If requesting such a change in behavior is not an
option, it would still be useful for the wiki to
explicitly mention the umask defaults that apply
in the absence of a mode.

(I’m happy to do the wiki edit if it’s too much of a bother)

Faiz

On Fri, 3 Jun 2011 12:27:16 -0700
Adam Jacob adam@opscode.com wrote:

This is not always the default - it’s going to be a reflection of
the user who runs chef’s umask. Most operating systems will have
this be 0600, but not all of them will - so you can’t rely on it
as a general rule.

Adam

On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray matt@opscode.com wrote:

I verified this and I’ve updated the Template entry on the
Resources page to reflect the default.
http://wiki.opscode.com/display/chef/Resources#Resources-Template

Thanks,
Matt Ray
Senior Technical Evangelist | Opscode Inc.
matt@opscode.com | (512) 731-2218
Twitter, IRC, GitHub: mattray

On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi faiz@dreamarts.co.jp
wrote:

It appears that if one does not specify a mode,
files generated/overwritten by template resources
end up having permissions like -rw------- (0600).

This seems like a sane default. But maybe the
documentation should make this explicit.
Right now, the template resource wiki page
http://wiki.opscode.com/display/chef/Resources#Resources-Template
reads:

Attribute: mode
Description: "The octal mode of the file - 0755"
Default Value: (nothing here)

Take for example the simple case of managing /etc/hosts.
This file usually has permissions -rw-r–r--.

template '/etc/hosts’
source 'hosts.erb’
end

… will overwrite /etc/hosts as expected, but if one
forgets to pass in the mode attribute, '/etc/hosts’
ends up as readable only by root (i.e., -rw-------).

This is not really a major problem (I simply make sure
to pass in a mode explicitly).
but as a suggestion:

(1) For existing files that get ‘templated’,
chef-client could just leave the permissions untouched.

OR

(2) Fix the docs to make it very clear that unless
one specifies a mode explicitly, the file
created/overwritten by the template will end up
with the default mode (and that the default
mode is 0600, not 0755)

For the record, I’m still running 0.9.16.

Thanks,
Faiz


#10

On Fri, Jun 10, 2011 at 3:57 AM, Faiz Kazi faiz@dreamarts.co.jp wrote:

Here’s an ad-hoc patch we use locally to address this problem
(shown against v0.10).

Does cp truncate the target file then write it? I’d like to avoid that if
possible. Some daemons don’t like that.


#11

On 2011-06-15 08:02:36, Brian Akins wrote:

Does cp truncate the target file then write it? I’d like to avoid that if
possible. Some daemons don’t like that.

$ strace cp 1 2

open(“1”, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1048576, …}) = 0
open(“2”, O_WRONLY|O_TRUNC) = 4

/Allan

Allan Wind
Life Integrity, LLC
http://lifeintegrity.com


#12

On Wed, Jun 15, 2011 at 10:38 AM, Allan Wind
allan_wind@lifeintegrity.comwrote:

$ strace cp 1 2

open(“1”, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1048576, …}) = 0
open(“2”, O_WRONLY|O_TRUNC) = 4

Confirmed that FileUtils.cp does the same. Probably not a good thing.


#13

On Wednesday, June 15, 2011 at 8:43 AM, Brian Akins wrote:

On Wed, Jun 15, 2011 at 10:38 AM, Allan Wind <allan_wind@lifeintegrity.com (mailto:allan_wind@lifeintegrity.com)> wrote:

$ strace cp 1 2

open(“1”, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1048576, …}) = 0
open(“2”, O_WRONLY|O_TRUNC) = 4

Confirmed that FileUtils.cp does the same. Probably not a good thing.
The original behavior of these providers was to use FileUtils.cp, and this is why it was changed. That said, mv is only atomic for moves on the same partition. We had a discussion about this on the dev list a few weeks back in the context of Windows ACLs, which are similarly mangled when using mv.

My favored solution is to create a temporary file right next to the target file, so if you were writing /etc/chef/client.rb from a template, you would use /etc/chef/client.rb.RANDOM_SLUG as the temporary file. Of course, in the case that something has registered to watch this directory, you could get misbehavior, and extreme failure cases, such as segfaults in the ruby runtime could leave these files in that directory, which would be problematic for multi-file (e.g., conf.d and friends) configurations. It also does not solve the permissions issue raised here, but that can be fixed by patching the providers to set the desired file mode to the current one when not explicitly specified; there is nothing that can be done to make cp atomic.

I should also mention that I’m a bit uncomfortable with the outcome of converging a resource being dependent on initial system state outside of the resource, but then again, I would not go so far as to make file modes required for file resources. Suggestions or thoughts about this would be welcome.


Dan DeLeo


#14

On Wed, 15 Jun 2011 09:21:32 -0700
Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, June 15, 2011 at 8:43 AM, Brian Akins wrote:

On Wed, Jun 15, 2011 at 10:38 AM, Allan Wind
<allan_wind@lifeintegrity.com
(mailto:allan_wind@lifeintegrity.com)> wrote:

$ strace cp 1 2

open(“1”, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1048576, …}) = 0
open(“2”, O_WRONLY|O_TRUNC) = 4

Confirmed that FileUtils.cp does the same. Probably not a good
thing.
The original behavior of these providers was to use FileUtils.cp, and
this is why it was changed. That said, mv is only atomic for moves on
the same partition. We had a discussion about this on the dev list a
few weeks back in the context of Windows ACLs, which are similarly
mangled when using mv.

cp’s drawbacks - compared to mv - which are that
(a) it is not atomic and
(b) it truncates the file and then does a write
with the new contents -

  • are a problem in some case, sure. I think it
    depends on what kind of file is being template’d by
    chef.

One of the most frequent use cases is to automate
the editing of config files - something that without
chef, is done using a text editor. I’m guessing most
editors simply do an open() with WRONLY|TRUNC, then
write out the new contents. This is not any worse
than cp.

Take ed for instance:

test.txt contains only one line -> “The first line.\n”

echo -e ‘$\na\n#a new line\n.\nwq\n’ | strace ed test.txt


open(“test.txt”, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4

fd=3 seems to be a temp. file in this case.

write(3, “#a new line”, 11) = 11
lseek(3, 0, SEEK_SET) = 0
read(3, “The first line.#a new line”, 4096) = 26
fstat(4, {st_mode=S_IFREG|0644, st_size=0, …}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f44573a5000 write(4, “The first line.\n#a new line\n”, 28) = 28
close(4) = 0

So for the majority of config file updates,
chef calling FileUtils.cp does not seem any worse than
editing the files by hand. (It’s probably the
closest emulation of that behavior).

However, O_TRUNC might be a problem in other cases;
I haven’t come across one yet, but it’s probably just
a matter of time.

My favored solution is to create a temporary file right next to the
target file, so if you were writing /etc/chef/client.rb from a
template, you would use /etc/chef/client.rb.RANDOM_SLUG as the
temporary file. Of course, in the case that something has registered
to watch this directory, you could get misbehavior, and extreme
failure cases, such as segfaults in the ruby runtime could leave
these files in that directory, which would be problematic for
multi-file (e.g., conf.d and friends) configurations. It also does
not solve the permissions issue raised here, but that can be fixed by
patching the providers to set the desired file mode to the current
one when not explicitly specified; there is nothing that can be done
to make cp atomic.

That’s right… I think we’re dealing with the classic
difficulty of trying to ensure atomic file write operations
in a cross-platform manner.

Are the chances of
(a) a left-behind RANDOM_SLUG breaking a system after such
an extreme failure
much smaller than:
(b) a daemon being negatively impacted because of a
non-atomic config file update?

If Yes, and if (a) gives up atomicity, well why not.

I should also mention that I’m a bit uncomfortable with the outcome
of converging a resource being dependent on initial system state
outside of the resource, but then again, I would not go so far as to
make file modes required for file resources. Suggestions or thoughts
about this would be welcome.

That’s indeed a tricky question. I lean towards not changing the
property of a resource unless the change was specified, but I
also share your discomfort about this: The problem is that
there will remain an undocumented/unknown property of
the system (in this case the mode of a file) which is
vital to the system as a whole. (an unknown unknown)

Making the mode required could potentially do away with
all the ambiguity; but then that would break so many
recipes already in use.

One possible (though somewhat uncool) middle-ground approach would
be to print a converge-time warning when initial system state does
not match the resources’ defaults - and continue the converge keeping
the state unchanged - the risks of breaking a running system
because a file suddenly became unreadable by a daemon are very real.

I do think that running systems should be left to depend on
undocumented state. If a chef recipe worked well simply because say,
a certain library needed by some part of the system just happened
to be available, but this fact was never made explicit in the
recipe - then that situation needs to be identified and fixed.
(In this case, whether or not chef makes the the mode attribute
required for files). It’s a balance between that and the risk
of breaking something in production.

Faiz


#15

On Thu, 16 Jun 2011 11:25:00 +0900
Faiz Kazi faiz@dreamarts.co.jp wrote:

On Wed, 15 Jun 2011 09:21:32 -0700
I do think that running systems should be left to depend on
undocumented state. If a chef recipe worked well simply because say,

Typo. I meant:

I do think that running systems should not be left to depend on
undocumented state.

F


#16

On Jun 15, 2011, at 10:25 PM, Faiz Kazi wrote:

One of the most frequent use cases is to automate
the editing of config files - something that without
chef, is done using a text editor. I’m guessing most
editors simply do an open() with WRONLY|TRUNC, then
write out the new contents. This is not any worse
than cp.

Don’t a lot of them write to a tmp file then mv it over? Also, mostly we used to rsync files around, which can be made to do updates atomically.

To me it seems lame to claim "it’s no worse than " when the correct behavior is not incredibly hard to implement. My $.02 worth.

–Brian


#17

FYI - Because I misread (again) the notes on the wiki page as the default
(and then found this on the web) I modified the wiki page to make it clear
for all ‘mode’ options of resource that 0755 is not the default (and linked
to Adam’s reply within the list discussion)

HTH

Tim

On Fri, Jun 3, 2011 at 8:27 PM, Adam Jacob adam@opscode.com wrote:

This is not always the default - it’s going to be a reflection of the
user who runs chef’s umask. Most operating systems will have this be
0600, but not all of them will - so you can’t rely on it as a general
rule.

Adam

On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray matt@opscode.com wrote:

I verified this and I’ve updated the Template entry on the Resources
page to reflect the default.
http://wiki.opscode.com/display/chef/Resources#Resources-Template

Thanks,
Matt Ray
Senior Technical Evangelist | Opscode Inc.
matt@opscode.com | (512) 731-2218
Twitter, IRC, GitHub: mattray

On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi faiz@dreamarts.co.jp wrote:

It appears that if one does not specify a mode,
files generated/overwritten by template resources
end up having permissions like -rw------- (0600).

This seems like a sane default. But maybe the
documentation should make this explicit.
Right now, the template resource wiki page
http://wiki.opscode.com/display/chef/Resources#Resources-Template
reads:

Attribute: mode
Description: "The octal mode of the file - 0755"
Default Value: (nothing here)

Take for example the simple case of managing /etc/hosts.
This file usually has permissions -rw-r–r--.

template '/etc/hosts’
source 'hosts.erb’
end

… will overwrite /etc/hosts as expected, but if one
forgets to pass in the mode attribute, '/etc/hosts’
ends up as readable only by root (i.e., -rw-------).

This is not really a major problem (I simply make sure
to pass in a mode explicitly).
but as a suggestion:

(1) For existing files that get ‘templated’,
chef-client could just leave the permissions untouched.

OR

(2) Fix the docs to make it very clear that unless
one specifies a mode explicitly, the file
created/overwritten by the template will end up
with the default mode (and that the default
mode is 0600, not 0755)

For the record, I’m still running 0.9.16.

Thanks,
Faiz


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com

Tim Diggins
http://red56.co.uk
tim@red56.co.uk

07515 931 642 / +447515931642