FAQ
Recently, the issue of copying file modes from remote sources was discussed
on the puppet-users mailing list[1], although it equally applies to owner
and group.

One issue is what permissions to apply to newly created files when none are
specified? Historically, Puppet has always copied the permissions from the
file source to the newly created one. However, this causes problems on
Windows[2] agents due to the way that Puppet emulates POSIX permissions. We
break NTFS access control inheritance to ensure the effective permissions
are not greater than what Puppet has granted. It also causes problems on
*nix agents, when the files' source is remote and uid/gids are not
synchronized.

A second, but related issue, is that Puppet applies the same
copy-permissions logic to files that already exist. This goes against what
jcbollinger said, "unmanaged resources and resource properties should not
be modified by Puppet"[3], and what Nigel said, "A core principle of Puppet
is that you can choose to only manage the attributes of a resource that you
care about, and can leave the rest unmanaged."[4] However, this "bug" has
been around so long, at least 0.24.8, that we can't change behaviors in a
minor release.[5]

Patrick and I talked about this and would like to propose adding a file
parameter, something like `use_source_permissions`. If true and permissions
are unspecified, Puppet would continue copying source permissions as it
does today, for both newly created and existing files. This would be the
default.

If false and permission are unspecified, Puppet would never copy them from
the source. Instead the permission defaults for newly created files would
be based on the user that Puppet is running as. And the permissions for
existing files would be unmodified.

Doing so would provide a mechanism for resolving both #5240 and #18931.

Comments and feedback welcome.

Josh

[1]
https://groups.google.com/forum/#!msg/puppet-users/CI7pEUHknm4/x-hCGJn6Ms8J
[2] https://projects.puppetlabs.com/issues/18931
[3] https://groups.google.com/d/msg/puppet-users/CI7pEUHknm4/VtCl9YmeIS0J
[4] http://projects.puppetlabs.com/issues/5240#note-16
[5] https://projects.puppetlabs.com/issues/5240

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

Search Discussions

  • Jcbollinger at Feb 9, 2013 at 12:19 am

    On Thursday, February 7, 2013 7:48:58 PM UTC-6, Josh Cooper wrote:
    Recently, the issue of copying file modes from remote sources was
    discussed on the puppet-users mailing list[1], although it equally applies
    to owner and group.

    One issue is what permissions to apply to newly created files when none
    are specified? Historically, Puppet has always copied the permissions from
    the file source to the newly created one. However, this causes problems on
    Windows[2] agents due to the way that Puppet emulates POSIX permissions. We
    break NTFS access control inheritance to ensure the effective permissions
    are not greater than what Puppet has granted. It also causes problems on
    *nix agents, when the files' source is remote and uid/gids are not
    synchronized.

    A second, but related issue, is that Puppet applies the same
    copy-permissions logic to files that already exist. This goes against what
    jcbollinger said, "unmanaged resources and resource properties should not
    be modified by Puppet"[3], and what Nigel said, "A core principle of Puppet
    is that you can choose to only manage the attributes of a resource that you
    care about, and can leave the rest unmanaged."[4] However, this "bug" has
    been around so long, at least 0.24.8, that we can't change behaviors in a
    minor release.[5]

    Patrick and I talked about this and would like to propose adding a file
    parameter, something like `use_source_permissions`. If true and permissions
    are unspecified, Puppet would continue copying source permissions as it
    does today, for both newly created and existing files. This would be the
    default.

    If false and permission are unspecified, Puppet would never copy them from
    the source. Instead the permission defaults for newly created files would
    be based on the user that Puppet is running as. And the permissions for
    existing files would be unmodified.

    Doing so would provide a mechanism for resolving both #5240 and #18931.

    Comments and feedback welcome.
    I think this is a fine and useful idea, but I'm not sure it goes far
    enough. In the first place, it says nothing about uid / gid, even though
    it is acknowledged that the same problem applies to them. Is that just an
    oversight?

    In the second place, there is another usage mode to consider: what if you
    want to copy source permissions / uid / gid in the event that Puppet
    creates the file (since you cannot create the file without choosing those
    properties somehow), but you do not want to enforce those properties on the
    file if it already exists? I'm not convinced that this case needs to be
    supported, but it should at least be considered.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Josh Cooper at Feb 9, 2013 at 3:08 am
    Hi John,
    On Fri, Feb 8, 2013 at 9:22 AM, jcbollinger wrote:

    On Thursday, February 7, 2013 7:48:58 PM UTC-6, Josh Cooper wrote:

    Recently, the issue of copying file modes from remote sources was
    discussed on the puppet-users mailing list[1], although it equally applies
    to owner and group.

    One issue is what permissions to apply to newly created files when none
    are specified? Historically, Puppet has always copied the permissions from
    the file source to the newly created one. However, this causes problems on
    Windows[2] agents due to the way that Puppet emulates POSIX permissions. We
    break NTFS access control inheritance to ensure the effective permissions
    are not greater than what Puppet has granted. It also causes problems on
    *nix agents, when the files' source is remote and uid/gids are not
    synchronized.

    A second, but related issue, is that Puppet applies the same
    copy-permissions logic to files that already exist. This goes against what
    jcbollinger said, "unmanaged resources and resource properties should not be
    modified by Puppet"[3], and what Nigel said, "A core principle of Puppet is
    that you can choose to only manage the attributes of a resource that you
    care about, and can leave the rest unmanaged."[4] However, this "bug" has
    been around so long, at least 0.24.8, that we can't change behaviors in a
    minor release.[5]

    Patrick and I talked about this and would like to propose adding a file
    parameter, something like `use_source_permissions`. If true and permissions
    are unspecified, Puppet would continue copying source permissions as it does
    today, for both newly created and existing files. This would be the default.

    If false and permission are unspecified, Puppet would never copy them from
    the source. Instead the permission defaults for newly created files would be
    based on the user that Puppet is running as. And the permissions for
    existing files would be unmodified.

    Doing so would provide a mechanism for resolving both #5240 and #18931.

    Comments and feedback welcome.
    I think this is a fine and useful idea, but I'm not sure it goes far enough.
    In the first place, it says nothing about uid / gid, even though it is
    acknowledged that the same problem applies to them. Is that just an
    oversight?
    Good point, I didn't explicitly mention this, but yes, I am proposing
    that this behavior affect all file permissions - uid, gid, and mode.
    In the second place, there is another usage mode to consider: what if you
    want to copy source permissions / uid / gid in the event that Puppet creates
    the file (since you cannot create the file without choosing those properties
    somehow), but you do not want to enforce those properties on the file if it
    already exists? I'm not convinced that this case needs to be supported, but
    it should at least be considered.
    So this is really the heart of issue #5240. Perhaps
    use_source_permissions needs to be more than a boolean? Something
    like:

    use_source_permissions
       :always - what puppet does today (default)
       :creates - only apply source permissions when creating a file
       :never - what I was proposing

    Also, I didn't explicitly mention this, but I am proposing that this
    affect all types of file resources (file, dir, link), not just files.

    Josh

    --
    Josh Cooper
    Developer, Puppet Labs

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jakov Sosic at Feb 9, 2013 at 1:21 am

    On 02/08/2013 06:46 PM, Josh Cooper wrote:
    Hi John,

    On Fri, Feb 8, 2013 at 9:22 AM, jcbollinger
    wrote:
    On Thursday, February 7, 2013 7:48:58 PM UTC-6, Josh Cooper wrote:

    Recently, the issue of copying file modes from remote sources
    was discussed on the puppet-users mailing list[1], although it
    equally applies to owner and group.

    One issue is what permissions to apply to newly created files
    when none are specified? Historically, Puppet has always copied
    the permissions from the file source to the newly created one.
    However, this causes problems on Windows[2] agents due to the way
    that Puppet emulates POSIX permissions. We break NTFS access
    control inheritance to ensure the effective permissions are not
    greater than what Puppet has granted. It also causes problems on
    *nix agents, when the files' source is remote and uid/gids are
    not synchronized.

    A second, but related issue, is that Puppet applies the same
    copy-permissions logic to files that already exist. This goes
    against what jcbollinger said, "unmanaged resources and resource
    properties should not be modified by Puppet"[3], and what Nigel
    said, "A core principle of Puppet is that you can choose to only
    manage the attributes of a resource that you care about, and can
    leave the rest unmanaged."[4] However, this "bug" has been around
    so long, at least 0.24.8, that we can't change behaviors in a
    minor release.[5]

    Patrick and I talked about this and would like to propose adding
    a file parameter, something like `use_source_permissions`. If
    true and permissions are unspecified, Puppet would continue
    copying source permissions as it does today, for both newly
    created and existing files. This would be the default.

    If false and permission are unspecified, Puppet would never copy
    them from the source. Instead the permission defaults for newly
    created files would be based on the user that Puppet is running
    as. And the permissions for existing files would be unmodified.

    Doing so would provide a mechanism for resolving both #5240 and
    #18931.

    Comments and feedback welcome.
    I think this is a fine and useful idea, but I'm not sure it goes
    far enough. In the first place, it says nothing about uid / gid,
    even though it is acknowledged that the same problem applies to
    them. Is that just an oversight?
    Good point, I didn't explicitly mention this, but yes, I am
    proposing that this behavior affect all file permissions - uid, gid,
    and mode.
    In the second place, there is another usage mode to consider: what
    if you want to copy source permissions / uid / gid in the event
    that Puppet creates the file (since you cannot create the file
    without choosing those properties somehow), but you do not want to
    enforce those properties on the file if it already exists? I'm not
    convinced that this case needs to be supported, but it should at
    least be considered.
    So this is really the heart of issue #5240. Perhaps
    use_source_permissions needs to be more than a boolean? Something
    like:

    use_source_permissions :always - what puppet does today (default)
    :creates - only apply source permissions when creating a file :never
    - what I was proposing

    Also, I didn't explicitly mention this, but I am proposing that this
    affect all types of file resources (file, dir, link), not just
    files.
    Could this attribute be shorter? Like 'use_source_perm' or just
    'source_perms'?

    And I agree with this solution, and in the next major version simply
    change default to never and that's it :)


    --
    Jakov Sosic
    www.srce.unizg.hr

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Keith Burdis at Feb 9, 2013 at 9:22 am
    Since it would apply to more than just permissions perhaps
    'source_attributes' would be better?

       - Keith
    On 9 Feb 2013 01:21, "Jakov Sosic" wrote:
    On 02/08/2013 06:46 PM, Josh Cooper wrote:

    Hi John,

    On Fri, Feb 8, 2013 at 9:22 AM, jcbollinger
    wrote:
    On Thursday, February 7, 2013 7:48:58 PM UTC-6, Josh Cooper wrote:


    Recently, the issue of copying file modes from remote sources
    was discussed on the puppet-users mailing list[1], although it
    equally applies to owner and group.

    One issue is what permissions to apply to newly created files
    when none are specified? Historically, Puppet has always copied
    the permissions from the file source to the newly created one.
    However, this causes problems on Windows[2] agents due to the way
    that Puppet emulates POSIX permissions. We break NTFS access
    control inheritance to ensure the effective permissions are not
    greater than what Puppet has granted. It also causes problems on
    *nix agents, when the files' source is remote and uid/gids are
    not synchronized.

    A second, but related issue, is that Puppet applies the same
    copy-permissions logic to files that already exist. This goes
    against what jcbollinger said, "unmanaged resources and resource
    properties should not be modified by Puppet"[3], and what Nigel
    said, "A core principle of Puppet is that you can choose to only
    manage the attributes of a resource that you care about, and can
    leave the rest unmanaged."[4] However, this "bug" has been around
    so long, at least 0.24.8, that we can't change behaviors in a
    minor release.[5]

    Patrick and I talked about this and would like to propose adding
    a file parameter, something like `use_source_permissions`. If
    true and permissions are unspecified, Puppet would continue
    copying source permissions as it does today, for both newly
    created and existing files. This would be the default.

    If false and permission are unspecified, Puppet would never copy
    them from the source. Instead the permission defaults for newly
    created files would be based on the user that Puppet is running
    as. And the permissions for existing files would be unmodified.

    Doing so would provide a mechanism for resolving both #5240 and
    #18931.

    Comments and feedback welcome.
    I think this is a fine and useful idea, but I'm not sure it goes
    far enough. In the first place, it says nothing about uid / gid,
    even though it is acknowledged that the same problem applies to
    them. Is that just an oversight?
    Good point, I didn't explicitly mention this, but yes, I am
    proposing that this behavior affect all file permissions - uid, gid,
    and mode.

    In the second place, there is another usage mode to consider: what
    if you want to copy source permissions / uid / gid in the event
    that Puppet creates the file (since you cannot create the file
    without choosing those properties somehow), but you do not want to
    enforce those properties on the file if it already exists? I'm not
    convinced that this case needs to be supported, but it should at
    least be considered.
    So this is really the heart of issue #5240. Perhaps
    use_source_permissions needs to be more than a boolean? Something
    like:

    use_source_permissions :always - what puppet does today (default)
    :creates - only apply source permissions when creating a file :never
    - what I was proposing

    Also, I didn't explicitly mention this, but I am proposing that this
    affect all types of file resources (file, dir, link), not just
    files.
    Could this attribute be shorter? Like 'use_source_perm' or just
    'source_perms'?

    And I agree with this solution, and in the next major version simply
    change default to never and that's it :)


    --
    Jakov Sosic
    www.srce.unizg.hr

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to puppet-users+unsubscribe@**googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
    .
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/**group/puppet-users?hl=en<http://groups.google.com/group/puppet-users?hl=en>
    .
    For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
    .

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nikola Petrov at Feb 9, 2013 at 2:05 am
    I have seen this issue for sure many times. I always forget this and
    when I see it while running with --noop, I change the owner and the
    group on the file resource. I am +1 on fixing this to have a more
    deterministic behaviour

    Best, Nikola
    On Thu, Feb 07, 2013 at 05:48:58PM -0800, Josh Cooper wrote:
    Recently, the issue of copying file modes from remote sources was discussed
    on the puppet-users mailing list[1], although it equally applies to owner
    and group.

    One issue is what permissions to apply to newly created files when none are
    specified? Historically, Puppet has always copied the permissions from the
    file source to the newly created one. However, this causes problems on
    Windows[2] agents due to the way that Puppet emulates POSIX permissions. We
    break NTFS access control inheritance to ensure the effective permissions
    are not greater than what Puppet has granted. It also causes problems on
    *nix agents, when the files' source is remote and uid/gids are not
    synchronized.

    A second, but related issue, is that Puppet applies the same
    copy-permissions logic to files that already exist. This goes against what
    jcbollinger said, "unmanaged resources and resource properties should not
    be modified by Puppet"[3], and what Nigel said, "A core principle of Puppet
    is that you can choose to only manage the attributes of a resource that you
    care about, and can leave the rest unmanaged."[4] However, this "bug" has
    been around so long, at least 0.24.8, that we can't change behaviors in a
    minor release.[5]

    Patrick and I talked about this and would like to propose adding a file
    parameter, something like `use_source_permissions`. If true and permissions
    are unspecified, Puppet would continue copying source permissions as it
    does today, for both newly created and existing files. This would be the
    default.

    If false and permission are unspecified, Puppet would never copy them from
    the source. Instead the permission defaults for newly created files would
    be based on the user that Puppet is running as. And the permissions for
    existing files would be unmodified.

    Doing so would provide a mechanism for resolving both #5240 and #18931.

    Comments and feedback welcome.

    Josh

    [1]
    https://groups.google.com/forum/#!msg/puppet-users/CI7pEUHknm4/x-hCGJn6Ms8J
    [2] https://projects.puppetlabs.com/issues/18931
    [3] https://groups.google.com/d/msg/puppet-users/CI7pEUHknm4/VtCl9YmeIS0J
    [4] http://projects.puppetlabs.com/issues/5240#note-16
    [5] https://projects.puppetlabs.com/issues/5240
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Llowder at Feb 8, 2013 at 2:12 pm

    On Friday, February 8, 2013 6:56:55 AM UTC-6, nikolavp wrote:
    I have seen this issue for sure many times. I always forget this and
    when I see it while running with --noop, I change the owner and the
    group on the file resource. I am +1 on fixing this to have a more
    deterministic behaviour
    It seems like a good idea, though to maintain backwards compatibilty, would
    it be better to have the proposed fixed default to false (ie, maintain
    current behavior)?


    Best, Nikola
    On Thu, Feb 07, 2013 at 05:48:58PM -0800, Josh Cooper wrote:
    Recently, the issue of copying file modes from remote sources was discussed
    on the puppet-users mailing list[1], although it equally applies to owner
    and group.

    One issue is what permissions to apply to newly created files when none are
    specified? Historically, Puppet has always copied the permissions from the
    file source to the newly created one. However, this causes problems on
    Windows[2] agents due to the way that Puppet emulates POSIX permissions. We
    break NTFS access control inheritance to ensure the effective
    permissions
    are not greater than what Puppet has granted. It also causes problems on
    *nix agents, when the files' source is remote and uid/gids are not
    synchronized.

    A second, but related issue, is that Puppet applies the same
    copy-permissions logic to files that already exist. This goes against what
    jcbollinger said, "unmanaged resources and resource properties should not
    be modified by Puppet"[3], and what Nigel said, "A core principle of Puppet
    is that you can choose to only manage the attributes of a resource that you
    care about, and can leave the rest unmanaged."[4] However, this "bug" has
    been around so long, at least 0.24.8, that we can't change behaviors in a
    minor release.[5]

    Patrick and I talked about this and would like to propose adding a file
    parameter, something like `use_source_permissions`. If true and
    permissions
    are unspecified, Puppet would continue copying source permissions as it
    does today, for both newly created and existing files. This would be the
    default.

    If false and permission are unspecified, Puppet would never copy them from
    the source. Instead the permission defaults for newly created files would
    be based on the user that Puppet is running as. And the permissions for
    existing files would be unmodified.

    Doing so would provide a mechanism for resolving both #5240 and #18931.

    Comments and feedback welcome.

    Josh

    [1]
    https://groups.google.com/forum/#!msg/puppet-users/CI7pEUHknm4/x-hCGJn6Ms8J
    [2] https://projects.puppetlabs.com/issues/18931
    [3]
    https://groups.google.com/d/msg/puppet-users/CI7pEUHknm4/VtCl9YmeIS0J
    [4] http://projects.puppetlabs.com/issues/5240#note-16
    [5] https://projects.puppetlabs.com/issues/5240
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Josh Cooper at Feb 9, 2013 at 2:35 am
    Hi,
    On Fri, Feb 8, 2013 at 5:42 AM, llowder wrote:

    On Friday, February 8, 2013 6:56:55 AM UTC-6, nikolavp wrote:

    I have seen this issue for sure many times. I always forget this and
    when I see it while running with --noop, I change the owner and the
    group on the file resource. I am +1 on fixing this to have a more
    deterministic behaviour
    It seems like a good idea, though to maintain backwards compatibilty, would
    it be better to have the proposed fixed default to false (ie, maintain
    current behavior)?
    "If true and permissions are unspecified, Puppet would continue
    copying source permissions as it does today, for both newly created
    and existing files. This would be the default."

    Josh

    --
    Josh Cooper
    Developer, Puppet Labs

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Klavs Klavsen at Sep 19, 2013 at 6:25 am
    This would be a GREAT benefit, and I for one, would definetely make it my
    File default :)

    source_permissions is a fine name for it.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kylo Ginsberg at Nov 19, 2013 at 5:56 pm
    Hello all,

    Just a quick update on this issue. We're planning to fix this for 3.4 and
    there's a pull request at:

    https://github.com/puppetlabs/puppet/pull/2087

    Also, after some discussion with Nick F, we renamed the 3 values of
    source_permissions to:

    use, use_when_creating, ignore

    Thanks for any comments. It will be great to have this issue addressed!

    Kylo

    --
    Kylo Ginsberg
    kylo@puppetlabs.com

    *Join us at PuppetConf 2014, September 23-24 in San Francisco*

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CALsUZFF7w4E4WJFOqDYkfPGpypffoZmLkp%3D6K0%3DCMyyA%3D0cWng%40mail.gmail.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedFeb 8, '13 at 1:49a
activeNov 19, '13 at 5:56p
posts10
users8
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase