Item9468: Refactor Support.SettingFileAccessRightsLinuxUnix so we can link from Configure

Configure in trunk tries to be helpful by giving errors and warnings about file permissions/modes. For example:

Error: 2524 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} (0777) and {RCS}{dirPermission} (0755) are set correctly for your environment and correct the file permissions listed below.

3 reasons why this is really problematic:

1. Directories and files are tested separately. No easy chmod to change all.
2. No help is provided how to fix this (except for "correct the file permissions listed below").
3. Symbolic links will not be changed. So anything pseudo-install='ed with =-link is not set correctly, giving a permanent error (and causing hours of search and try to fix this).

Short discussion on IRC:

[13:50:06] <uebera||> Why not use a 'subscript' which locates all links (find . -type l) and sets their mode to that of the file/directory it links to? Using linux, this is a no-op, using OSX, this should fix things...
[13:50:55] <pharvey> find may not be available on windows
[13:51:27] <uebera||> Perl should be, yes? :)
[13:51:33] <uebera||> (in our case)
[13:51:40] <pharvey> I hope so :)
[13:52:09] <ArthurClemens> find will find the symbolic links, but you need to go to the original file
[13:52:24] <ArthurClemens> and then differentiate between files and dirs
[13:53:08] <pharvey> ArthurClemens: are you getting this on directories, or files too?
[13:54:19] <uebera||> readlink() gets you the destination of a symlink. cf. http://stackoverflow.com/questions/420058/how-do-i-copy-symbolic-links-in-perl
[13:54:42] <ArthurClemens> depends on the mode of the original, file or dir
[13:57:20] <ArthurClemens> meaning we could provide a perl script to set all correct permissions, be it file, directory or symlink?
[13:57:36] <uebera||> Yes, we could.

Foswiki 1.1 will introduce the new, user friendly Configure. I hope we don't screw it by introducing this kind of user interaction. In that case Foswiki, like TWiki, will always seem to be too hard to install.

-- ArthurClemens - 14 Aug 2010

Do non-developer installs ever run pseudo-install and symlink the internal files/directories within foswiki? If we disable these warnings to accommodate the pseudo-installed user, it seems that we would be hurting the normal installation.

A new foswiki install should not really encounter any of these errors unless we ship bad defaults in the tarball. Extensions also should be correct unless we have packaging errors. I this is specific to the OSX install, we may need to disable or modify the checks as done for Windows.

In the above example, I suspect that the filePermission (777) has been modified from the default installation. This is an "expert" setting, so the errors occur because the foswiki install defaults to 644 for files.

Another suggestion was to install a "fix permissions" button. But that would have to wait for post 1.1 due to the feature freeze. The directory/file permission check was actually also in 1.0.x, but excluded everything except svn directories IIRC, so it was broken.

One reason for needing the checker is that 1.0.x in suexec apache environments was creating directories with the wrong permissions due to suexec safe umask override. That's been fixed, but sites may have occasional bad directory permissions throughout the install.

As far as directories and files needing different permissions / chmod, the +x permission on a directory allows read of the directory. +x on the file allow the file to be executed - they have different meanings. We should not be using +x on any web accessible data files.

-- GeorgeClark - 15 Aug 2010

I have to agree with George. These warnings are invaluable for any casual foswiki admin who manipulates their data and pub manually. The most we can do for 1.1 is ship something in tools.

Otherwise, maybe we can figure out if there is a MacOS-specific bug here.

-- PaulHarvey - 16 Aug 2010

I cannot see that release blocking stuff is left on this one. Or what the corrective action is

The feature works the way we agreed it should work almost a month ago. And the symlink issue is a developer pseudo-install problem which in fact may not even be a real problem.

It does not hit an end user with a normal installation. I will no action this. Reopen if there is a specific UI enhancement that you feel can make the reporting even better

Forget all about having configure correcting access rights. Configure runs as the apache user. Apache can not change access rights when the error is that a file is read only for Apache. This requires that mr root fires up his terminal.

-- KennethLavrsen - 19 Aug 2010

I have given 3 reasons above. You say that number 3, the symbolic links, will not occur in Real Life - I have no argument against that. But reasons 1 and 2 are not resolved.

Mu suggestion would be to add extra information:

<p>
<strong>TIP: </strong> To change file and directory permissions on UNIX or Linux servers, use:
</p>
<p>
<code>
find $Foswiki::cfg{DataDir} -type d -print0 |xargs -0 sudo chmod $dperm # directories <br />
find $Foswiki::cfg{DataDir} -type f -print0 |xargs -0 sudo chmod $fperm # files
</code>
</p>

It would be better to have separate instructions for Windows.

Setting to "normal" and "new".

-- ArthurClemens - 21 Aug 2010

Rather than adding more inline docs to configure, would it be acceptable to point users to SettingFileAccessRightsLinuxUnix

-- GeorgeClark - 22 Aug 2010

A refactored help topic would do.

-- ArthurClemens - 22 Aug 2010

Changed title from "Configure gives error feedback on file permissions that cannot be changed easily".

I think SettingFileAccessRightsLinuxUnix should get sections for the major platforms and hosting.

-- ArthurClemens - 23 Aug 2010

Changing this to No Action. I'm not clear what we would have to do to fix this and permission checking is tenuous at best. AFS, SELinux, lots of cases where it won't work.

-- Main.GeorgeClark - 06 Jul 2015 - 03:28

Commenting is disabled while not logged in