Hi John, On Fri, Feb 8, 2013 at 9:22 AM, jcbollinger <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
