Feature Proposal: Review file permissions for consistency and implement checking/fixup

Motivation

There are some inconsistencies between default file permissions set by BuildContrib and the {RCS}{filePermission} and {dirPermission} defaults. Also, the defaults are "world readable" which is probably not advisable on shared hosting systems.

Description and Documentation

The Checkers in 1.1 will currently check files for required minimum read / write access, and as of r7767, will also check directories against {RCS}{dirPermission}. However in attempting to check files against {RCS}{filePermission} large numbers of errors were encountered. BuildContrib sets the default permission for .txt files, and files in the pub directory to 664, {RCS}{filePermission} is 644. So most extension attachments and topics result in a mismatch.

• Review the current default for directory and file system permissions used by {RCS}, BuildContrib, and the extension installer.
• Determine if current defaults are appropriate for shared and other environments, and set rational defaults
• Review/extend the Configure Checkers to better determine if appropriate permissions are in place.
  • May need setting or button to check all files rather than stop at PathCheckLimit
• Add a "fix permissions" button to configure.
• Should extension installer set permissions per manifest, or should the {RCS}{...Permission} settings override for the pub & data directories.
  • This would allow a local site requiring more restrictive permissions to control them in LocalSite.cfg
• Should configure have a set of configurable permissions - to allow locally modified file permissions for all directories?
• Should bin/configure permission settings be better understandable by the non-Linux administrator to further minimize errors?

Examples

See Tasks/Item9074. Tasks/Item6065, and Tasks/Item709 for other permissions related notes. Also InstallStepSetPermissions, and SettingFileAccessRightsLinuxUnix.

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: GeorgeClark - 13 Jun 2010

Discussion

Interesting. On one hand, I feel that we should avoid more configure options. On the other, it's clearly not the case for most basic installations to have filesystem permissions different to that configured for RCS.

Perhaps we are getting to the point where we just need a simple tool for the common/beginner installation, without getting in the way of the more special installations.

And to do that I think it is acceptable that we just have a button to check permissions are 1) readable; 2) writable; 3) align with {RCS}{...Permission}

And so, apart from implementing such a button in configure, we do need to rationalise permissions shipped in the distribution such that this feature does not make noise on a normal/default install.

-- PaulHarvey - 14 Jun 2010

Yeah, the more I use (and love) configure, the more I think we need more buttons to do the work

For example, the checkers for the Logdir parameters are very useful, but when they say one should remove the setting {blah}, it would be so much nicer to just click "Ok, do it", and be done with it.

But as George said today, maybe for 2.0

-- OlivierRaginel - 14 Jun 2010

See Tasks.Item9211

-- KennethLavrsen - 27 Jun 2010

Note that the permission problem for hosted sites is more difficult than just a perl -r -w -x type test. In an suexec environment the perl scripts are running under a different user:group than the server. So files accessed outside of Foswiki using the pub/ URL path are accessed with a different user. So perl -r -w -x may succeed while the file is still unreadable by the server.

We've had users encounter this issue on IRC. Plus a bug in 1.0 would result in Foswiki creating directories with incorrect permissions due to umask enforcement by the suexec So implementation of the permission check is to try to catch file system errors caused by broken 1.0.9 in hosted environments.

-- GeorgeClark - 27 Jun 2010

A similar problem arises on the AFS (Andrew File System): Although there are *nix-style permissions, AFS actually offers a more fine-grained rights management (for various users and groups and on more rights levels). This means that checking the *nix permissions does not make any sense since Foswiki's Perl scripts are going to be run under a specific AFS user whose permissions have to be checked with different commands.

The only solutions I can see for this are:

1. Make permission checks optional (easy, short term).
2. Evaluate the file system and web server user to determine appropriate checks (complicated).
3. Test by reading, creating, writing to files (most fail-safe but probably making the configure script run a long time).

What about a combination of the first and last approach - making permission checks optional and using the fail-safe method of try and catch?

(As a note: I am very new to Foswiki and esp. its installation. So please forgive me if I didn't get one or the other point here.)

List of related task items:

• Tasks/Item709 (Closed)
• Tasks/Item6065 (No Action Required)
• Tasks/Item9074 (Closed)
• Tasks/Item9211 (Closed)

-- AndreasKeil - 24 Oct 2010

I just added Tasks/Item9990 (No Action Required) to address this file system problem.

-- AndreasKeil - 11 Nov 2010

Changing this to Parked. Note that we've fixed Foswiki 2.0 to use filetest 'access'; which might address the AFS and other file system issues. Anyway, needs a developer.

-- GeorgeClark - 19 Nov 2015

Commenting is disabled while not logged in