Issue #5240 has been updated by Reid Vandewiele.
Just ran into an interesting possible cause of mayhem with the existing behavior. Admittedly, for mayhem to occur in the to-be-described manner some crime of idiocy has to be committed by the sysadmin, but such things have been known to happen. Let us suppose... In the beginning, for a given site, a global default exists for the File resource which specifies `owner => "root"` and `group => "root"`. Resources in a site's puppet config are declared without owner/group, relying on the global default. When hosts are initially puppeted, these files are created, owner and group will be assigned, and thus far in the story all is well. Further suppose now that some time down the road, the global default is removed from the config. With the current behavior, a File resource definition which specifies no owner or group will result in existing files on puppeted hosts now being chown'd to the uid/gid of the file on the puppetmaster. This might result in some mayhem, especially if something like /etc/pam.conf is puppeted. The current behavior seems very questionable in this situation. If a file resource is defined, given content, but not given an explicit owner/group, there is certainly a conundrum regarding what to do about owner/group if the file need be created. However, in the situation where the file already exists on the client it seems the sane thing to do regarding owner/group when nothing is specified, is nothing. In my situation I was ripping out and converting to vanilla puppet an ancient wrapper-type define for the File resource (2005 era, a couple of predecessors ago) which had the side effect of acting as a global owner/group default. However, I can also imagine the situation where someone would like to puppet a file which they know to exist already but need to modify the content for. As a kind of side observation, in the case of root owner/group files (which comprise a huge segment of the file population likely to be puppeted) it doesn't really make sense for files to be owned/grouped root on the puppetmaster, where it is unlikely that the puppetmaster is running as root. This pretty much means that it doesn't make sense for the owner/group of the puppetmaster copy of the file to define the default owner/group instantiated on the client. ---------------------------------------- Bug #5240: Default ownership https://projects.puppetlabs.com/issues/5240 Author: Markus Falb Status: Investigating Priority: Normal Assignee: Nigel Kersten Category: file Target version: Affected Puppet version: 0.25.5 Keywords: Branch: file { "/bla/bla.txt": ensure => file, source => "puppet:///bla/bla.txt", } The file on puppetmaster belongs to user x with uid y and it is created on the client with uid y whatever user this translates to. A user for uid y may or may not exists on the client. uids/gids on puppetmaster and puppetd are not necessarily synchronised. If I forget to set a ownership explicitly possibly unrelated users on the client may access files. This behaviour is potentially unsecure. On puppetmaster (note the -n switch): #$ ls -n bla.txt -rw-r--r-- 1 502 301 4 8 Nov 16:25 bla.txt The result on the client (user/group does not exist): #$ ls -l bla.txt -rw-r--r-- 1 502 301 4 Nov 8 16:39 bla.txt Expected behaviour: I would like to rely on reasonable defaults. When no user/group is explicitly defined, files should be created with ownership of the user puppet runs as: #$ ls -l bla.txt -rw-r--r-- 1 root root 4 Nov 8 16:39 bla.txt -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
