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.
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.
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.
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.
Hi, On Fri, Feb 8, 2013 at 5:42 AM, llowder <llowderiv@gmail.com> 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.
Hi John, On Fri, Feb 8, 2013 at 9:22 AM, jcbollinger <John.Bollinger@stjude.org> 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.
On 02/08/2013 06:46 PM, Josh Cooper wrote:> Hi John, > > On Fri, Feb 8, 2013 at 9:22 AM, jcbollinger > <John.Bollinger@stjude.org> 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.
Since it would apply to more than just permissions perhaps ''source_attributes'' would be better? - Keith On 9 Feb 2013 01:21, "Jakov Sosic" <jsosic@srce.hr> wrote:> On 02/08/2013 06:46 PM, Josh Cooper wrote: > >> Hi John, >> >> On Fri, Feb 8, 2013 at 9:22 AM, jcbollinger >> <John.Bollinger@stjude.org> 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.
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.
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.