[PUP-4434] File type can't only use setgid for directory, and skip over files Created: 2015/04/17  Updated: 2017/01/30  Resolved: 2017/01/30

Status: Closed
Project: Puppet
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: Lee Lowder Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: customer, support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
CS Priority: Trivial


(Note, this was manually copied from a redmine ticket)

Given a directory:

$dir = '/some/dir/'

You may wish to recursively ensure a certain mode such as: u=rw,g=r As you all know, this cleverly adds +x to directories, but not to files. (good!) You may also decide that you’d like to setgid (+s) for the directory…

File { "${dir}":
        mode => 'u=rw,g=rs,o=r',
        recurse => true,

… but NOT for it’s contents. These two semantics are very different, since setgid for a directory, ensures new files/dirs have the group you want, however adding this to an executable file can be quite dangerous!

You can’t do this:

File { "${dir}":
        mode => 'u=rw,g=r,o=r',
        recurse => true,
File { "${dir}":
        mode => 'g+s',
        recurse => false,

because that’s a duplicate definition. So: by default, I think:
1. +s for g should act like +x currently does (except opposite) — for +s only apply it to the directory, even when recurse is true.
2. If some flag like recurse_setgid => true, then you can recursively add the +s

I marked this as high, because I think the current behaviour is very dangerous.

I stumbled upon this problem when I realized setgid is a useful property to add to /etc/puppet/, but not for /etc/puppet/files/*


exec { "/bin/chmod g+s ${dir}":
    onlyif => "/usr/bin/test -d '${dir}' && /usr/bin/test ! -g '${dir}'",
    require => File["${dir}"],

Comment by Lee Lowder [ 2015/04/17 ]

https://projects.puppetlabs.com/issues/20001 (original ticket)

Comment by Eric Sorenson [ 2017/01/30 ]

Gonna mark this as closed/wont'fix since it is quite a rare issue and there is a valid workaround.

Generated at Tue Jul 14 04:19:26 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.