The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #2451

File type should support separate directory permissions

Added by Lawrence Ludwig over 5 years ago. Updated over 2 years ago.

Status:AcceptedStart date:07/27/2009
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:file
Target version:-
Affected Puppet version:0.24.8 Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

If you do:

file { '/tmp/test':
        mode => '644',
        ensure => directory,
}

[root@localhost manifests]# puppet resource_defaults.pp --verbose --debug
debug: Creating default schedules
debug: Failed to load library 'ldap' for feature 'ldap'
debug: Finishing transaction -606516548 with 0 changes
debug: //File[/tmp/test]: Changing mode
debug: //File[/tmp/test]: 1 change(s)
notice: //File[/tmp/test]/mode: mode changed '777' to '755'
debug: Finishing transaction -605478848 with 1 changes

The mode set it NOT correct it should be set to 644 for that folder. This is because of security reasons.

History

#1 Updated by Peter Meier over 5 years ago

http://www.wellho.net/mouth/2300_What-does-x-on-a-linux-directory-mean-.html gave me some reasons, why you’d like to have it like that. on the other side we might come with problems while recursively managing a directory.

for sure the best would be to not set the +x and to have maybe something like a auto_x_bit_on_directory option for the file resource type, to get the old behaviour back.

if we’re going to introduce the more strict way: this change might break a lot of existing configurations and we should first give a possiblitly to force the strict way and give a deprecation warning on the old way and then in a next major release change it to the other way.

#2 Updated by Luke Kanies over 5 years ago

  • Subject changed from File type does not set a folder permission properly to File type should support separate directory permissions
  • Category set to file
  • Status changed from Unreviewed to Accepted

This behaviour has worked well for most people so far, but I’m comfortable adding a ‘dirmode’ parameter; the behaviour would be the existing behaviour if dirmode is unspecified, and if it specified then the normal ‘mode’ parameter would just affect non-directories and ‘dirmode’ would only affect directories.

Is that acceptable?

#3 Updated by Lawrence Ludwig over 5 years ago

The issue is concerning security and the implied change, which is bad if someone is purposely setting a folder to have say 740 perms (to prevent directly listing). This was brought as an issue by two persons in the NYC Puppet Training course and would be a show stopper to use the File type. To me, this additional option would be an acceptable work around for recursion.

Either way if not recursive (creating a directory), the mode should be set to what’s specified, not what it think it’s best even if the user did it by mistake.

#4 Updated by Lawrence Ludwig over 5 years ago

A thread on the discussion.

http://groups.google.com/group/puppet-users/browse_thread/thread/2b708a9fab1cf709

#5 Updated by Trevor Vaughan over 5 years ago

I just responded to the thread and I feel that the default behaviour is correct for five nines of the cases out there.

In the off chance that you absolutely need a strange directory that can’t be traversed, the more secure option is to use POSIX extended ACLs, SELinux, or some other type of MAC overlay (GRSecurity, Solaris TE, whatever). Otherwise, I really don’t see the point of not having the execute bit on a directory.

I definitely see the point of not having the read or write bits, but if you’re trying to protect a directory from everyone but root, just use Posix extended ACLs and make the mode 751.

#6 Updated by Peter Meier over 5 years ago

Trevor Vaughan wrote:

I just responded to the thread and I feel that the default behaviour is correct for five nines of the cases out there.

  • 1 to stick with the default behaviour and to give the possibility to enforce the more strict behaviour with a flag.

Also available in: Atom PDF