Issue #5240 has been updated by Daniel Pittman.
> 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.
That said, I think this is something we absolutely *should* change.
> If the existing behavior has led to undesirable permissions, I don’t see any
> way to distinguish between:
>
> Deliberately not managing uid/gid
> Historical reliance upon implicit uid/gid for newly created files.
This has some measure of the NFS problem, though, which is that it
ships numeric (and potentially mismatched) UID and GID values across
the network, right? Even shipping named items can have undesirable
results, if the definition of groups and users is not centrally
managed or controlled. (...which includes semantics like "can this
UID be exposed to network facing attacks" and all.)
I would go as far as to argue that this implicit behaviour is a
security hole, in that it can change ownership of files unexpectedly,
and some common setups (eg: svn under Apache, and running a
post-commit hook to update your checkout of the Puppet files) will
result in network-accessible users running arbitrary code having
access to the target as well as source files...
I would honestly prefer a configuration setting, or `File { uid =>
inherit, gid => inherit }` declaration of intent. Probably behind a
regular deprecation pass and all, but even in 2.7.0.
----------------------------------------
Bug #5240: Default ownership for newly created files when uid/gid are
unspecified
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.
