Item9211: New access rights check in configure will create a support storm if not fixed

I have both in my production site and in my development sites a mix of file permissions of both topic .txt files and attachments where the permissions are either 755 or 775.

There is even a few 750 and 770 among the files.

The reason is that different plugins and different generations of TWiki and Foswiki has had different religions with respect to which default access rights we have.

Upgraders of Foswiki that come from the TWiki time or have many plugins will defacto have a mix of access right settings.

The way configure acts now it FLOODS the user with a long list of topics and pub files that do not match the RCS configure settings (something it does not even tell you).

Normally people should not have to alter the RCS settings unless they are on a shared host. This is why it is a hidden setting. It is a geek setting that most do not understand and should not have to understand.

We often have people with problems with access rights. Their problem is always that Foswiki does not have the needed access rights.

It is a very good idea that Foswiki checks that the access rights allow Foswiki to function.

But it is a wrong assumption that the RCS setting must match the file access rights. This will cause more confusion that it will repair.

Instead configure should use the approach: "Do I have the read or write access rights I need?". And warn if the access rights are too tight.

And it should not use the RCS setting for the check. On the contrary configure should check that the RCS setting is not set too tight.

We cannot release without addressing this. We will get a storm of support questions. Flooding with warnings - even if they can be ignored - is always a very bad thing.

-- 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 (fixed in 1.0.10) would result in Foswiki creating directories with incorrect permissions due to umask enforcement by the suexec.

From IRC discussion:

• Try to test for "sufficient" permission instead of exact match
• LImit number of failures reported to minimize noise.
• Document that expert RCS setting may be wrong - esp. if excessive failures.

-- GeorgeClark - 27 Jun 2010

Kenneth, I've checked in a fix that limits the reported failures to 10, and escalates the message to an error if exceeded. The new reported error is:

File/Directory permission mismatch reporting stopped at 10 warnings.
<nnn>directories or files have insufficient permissions.
Verify that the Store expert settings of {RCS}{filePermission} and {RCS}{dirPermission}
are set correctly for your environment and correct file system permissions if necessary.

I have not figured out how to check for "sufficient" permissions. And I'm concerned that on shared hosting sites, having extra permissions might be just as bad due to exposure to other users.

I've updated now to report "insufficient" permissions and to also count files with "excessive" permissions. The new message is:

nn files appear to have more access permission than is recommended.
Verify that the Store expert settings of {RCS}{filePermission} and {RCS}{dirPermission}
are set correctly for your environment and correct file system permissions if necessary.

Should we be starting to write up release notes for the changes and check them into the pending 1.1. release notes?

-- GeorgeClark - 04 Jul 2010

I have a couple of ideas to address these warning messages that don't have a recommended resolution. One possibility - write a file containing the details of the checks to the working/logs directory. And create a FileSystemPermissions that discusses the implications of the permissions, and somehow "include" the log of file system checks - visible by AdminGroup only. We could also attach the permissions fix script that is available on the support site. Any other suggestions?

-- GeorgeClark - 10 Jul 2010

I think what we have now in trunk is a substantial usability improvement for most Foswiki admins out there.

We really need to some reworking of the Configure UI to be able to offer more interactive controls, and that's not going to happen for 1.1.

So your suggestion to write a log and maybe ship a tool to act on that log is terrific.

At minimum, what remains to be done is a link to a topic in the System web with more detailed information and instructions.

-- PaulHarvey - 12 Jul 2010

George. The original concerns were..

• That it was reported as an error that files that permissions that were different from a hidden RCS setting. You changed this to reporting errors only when permissions are not open enough for Foswiki to work. So that primary concern is addressed.
• 2nd concern was the flood. When I reported the problem I had maybe 2000 files listed in the configure interface.

With respect to the warning/info message we have now the issues are

• You are not really told what the permissions should be.
• You have no clue what files we are talking about so you cannot address it.

The first could be solved by adding one extra sentence in the message saying something like "Recommended access rights are 755 where the 755 or whatever comes from the variable you use to test in the first place.

The 2nd could be done by listing up to 20 files for pub dir and up to 20 for data dir. And if there are more than 20 put "additional 32 files not listed" with 32 as an example. This way we do not flood and the admin can fix the 20 and run configure again and see the next 20. And once you have the 20 you can probably also see the pattern and fix more without having to run configure all the time

-- KennethLavrsen - 12 Jul 2010

Writing errors into a Foswiki topic doesn't sound like a great idea - we can't assume that the Foswiki system is fully functional while dealing with configure errors. It also raises security issues with exposing log files to the Wiki. Writing the log into the resources directory, so it can be served to the admin using the action=resource option is probably not ideal either - Logs need to stay in the working/logs directory.

It becomes a bit of a feature creep, but I'd like to add an "action=readlogs;log=" function to bin/configure. Initially locked down to only access configure_fscheck.log The checkers can then write detailed debug information to the log file, probably overwriting the file on each iteration. Initial version of the display would be a verbatim dump of the log contents.

This would be narrowly focused to just show checker errors. The error message would include a link to open the action=readlogs into a new target. Future feature proposal could address a more general log viewer.

-- GeorgeClark - 12 Jul 2010

Lavr, I missed your last post. I'll implement your two suggestions first and avoid the feature creep. I think logging all the messages to configure_fscheck.log probably makes sense as well, so I'll look into that too.

-- GeorgeClark - 12 Jul 2010

Lavr, Hopefully closer: Here are the latest messages. (RCS permissions changed from default to get some failures.)

Error: 1 directories or files have insufficient permissions. Insufficient permissions could prevent Foswiki or the web server from accessing or updating the files. Verify that the Store expert settings of {RCS}{filePermission} (0640) and {RCS}{dirPermission} (0750) are set correctly for your environment and correct the file permissions listed below.

Warning: 24 files appear to have more access permission than requested in the Store configuration.Excess permissions might allow other users on the web server to have undesired access to the files. Verify that the Store expert settings of {RCS}{filePermission} (0640} and {RCS}{dirPermission}) (0750}) are set correctly for your environment and correct the file permissions listed below.

(and then listed as a note)
First 10 detected errors of insufficient, or excessive permissions
/var/www/foswiki/trunk/core/pub/System/SkinTemplates - directory permission 0755 exceeds requested 0750
/var/www/foswiki/trunk/core/pub/System/WindowsInstallCookbook - directory insufficient permission: 0710 should be 0750

-- GeorgeClark - 12 Jul 2010

Solution has the right design now. This will fly. But code seems buggy.

I have a warning but no error for my pub directory even if it seems I should have first error followed by warnings.

My list looks like this in configure

Warning: 16 files appear to have more access permission than requested in the Store configuration. Excess permissions might allow other users on the web server to have undesired access to the files. Verify that the Store expert settings of {RCS}{filePermission} (0644} and {RCS}{dirPermission}) (0755}) are set correctly for your environment and correct the file permissions listed below.

First 10 detected errors of insufficient, or excessive permissions
/var/www/foswiki/core/data/Application - directory permission 0777 exceeds requested 0755
/var/www/foswiki/core/data/Application/OSS - directory permission 0777 exceeds requested 0755
/var/www/foswiki/core/data/Application/Requirements - directory permission 0777 exceeds requested 0755
/var/www/foswiki/core/data/Application/QMS - directory permission 0777 exceeds requested 0755
/var/www/foswiki/core/data/System/VarFOREACH.txt not writable
/var/www/foswiki/core/data/System/VarSEARCH.txt not writable
/var/www/foswiki/core/data/System/InterwikiPlugin.txt not writable
/var/www/foswiki/core/data/System/InterWikis.txt not writable
/var/www/foswiki/core/data/System/ReleaseNotes01x01.txt not writable
/var/www/foswiki/core/data/System/FormattedSearch.txt not writable
/var/www/foswiki/core/data/Motion - directory permission 0777 exceeds requested 0755
/var/www/foswiki/core/data/Projman - directory permission 0777 exceeds requested 0755
/var/www/foswiki/core/data/Myweb - directory permission 0777 exceeds requested 0755
/var/www/foswiki/core/data/Myweb/Movingsubweb - directory permission 0777 exceeds requested 0755
/var/www/foswiki/core/data/Myweb/Movingsubweb/Movingdeep - directory permission 0777 exceeds requested 0755
/var/www/foswiki/core/data/Myweb/Mysub - directory permission 0777 exceeds requested 0755
/var/www/foswiki/core/data/Myweb/Movingweb - directory permission 0777 exceeds requested 0755

It seems the only the warning is given and not the error. And the files for errors and warning are then mixed.

Oops. Yes, I see that. The intermixing is tough without redesigning the checker to save separate streams of errors. But certainly both errors should have been reported. I'll work on it.

-- GeorgeClark - 14 Jul 2010

Commenting is disabled while not logged in