You are here: Foswiki>Tasks Web>Item10873 (01 Oct 2011, GeorgeClark)Edit Attach

Item10873: Out-of-the-box problems in configure

Priority: Urgent
Current State: Duplicate
Released In: n/a
Target Release: minor
Applies To: Engine
Reported By: TimotheLitt
Waiting For:
Last Change By: GeorgeClark
I'm setting up an experimental Foswiki system (finally built a spare VM for the effort), running off trunk. The good news is that this is an install from an empty disk. And I like the new configure (not sure if I'll like merging my changes, but that's a ways off.)

The bad news is that, well, it has problems. One only gets to be a new user once, so here are the issues found so far, and some tools that, while they're evolving, may be of use to others.

Initial run of configure, setup all the paths, and hit save. Insecure dependency in mkdir while running with -T switch at /home/litt/wikisvn/foswiki/trunk/core/lib/Foswiki/Configure/Checkers/ line 30. on save. Sigh. You'll want to do something like the patch below.

I'm also unhappy about all the hard-coded oct(755)s in this code. I never allow world read.

I also don't understand why you are requiring group write to directories. If files are owned by apache.apache (say), 741 sufficies for directories. Only if the webserver is accessing directories via group permissions do (some) directories need to permit group write. Worse, consider owed by apache.ftp, where ftp has read access and we really don't want it to be able to write!

Configure also seems to complain about sgid ('s') on directories. You should recomend it - this ensures that new files get the directory's group, not the creator's. That's usually what one wants.

I like the validation, but we can't impose policy. This needs to be configurable.

I run selinux. Nice of configure to create directories - but it's then upset about the fact that the (per-directory) security contexts are all wrong. Sigh, again. I am refining a shell script that fixes all these. That script runs on both selinux and non-selinux systems. It's painfully slow, but it does document what context every directory - and the odd exception files - need to be assigned. And it handles the ugliness of running from trunk. I have a perl script that makes the svn trunk symlinks from pseudo-install relative - selinux has real problems when you follow a path from root (with user file contexts) instead of staying in the webserver-allowed contexts with ../.. . (Not to mention that it's a LOT easier to tar up an environment and move it with relative links!)

Perhaps configure can absorb the functions (it could be much more efficient). Bottom line is selinux needs to be a first-class environment for enterprise software like Foswiki.

I've seen a number of cases where default field values aren't being expanded. One I'm looking at right now is {Htpasswd}{FileName}, which shows $Foswiki::cfg{DataDir}/.htpasswd. That's were it comes from, but not what we want to display...

I also can't register - as soon as I put in an e-mail address, I get "Please correct the entered data before you continue". And the Register button is greyed-out. But, there is no error message on the screen!

So, I don't have a running system - yet - and I'm out of time for tonight -- oops - this morning.

Qick and dirty patch for creating directories:
---       (revision 11909)
+++       (working copy)
@@ -7,6 +7,11 @@
 use Foswiki::Configure::Checker ();
 our @ISA = ('Foswiki::Configure::Checker');

+sub untaint {
+   $_[0] =~ m/^(.*)$/;
+    return $1;
 sub check {
     my $this = shift;

@@ -27,7 +32,7 @@

     unless ( -d "$Foswiki::cfg{WorkingDir}" ) {
-        mkdir("$Foswiki::cfg{WorkingDir}", oct(755) )
+        mkdir(untaint( "$Foswiki::cfg{WorkingDir}" ), oct(755) )
           || return $this->ERROR(
 "$Foswiki::cfg{WorkingDir} does not exist, and I can't create it: $!"
@@ -40,7 +45,7 @@
 "$Foswiki::cfg{WorkingDir}/tmp already exists, but is not a directory"
-        elsif ( !mkdir( "$Foswiki::cfg{WorkingDir}/tmp", oct(1777) ) ) {
+        elsif ( !mkdir( untaint("$Foswiki::cfg{WorkingDir}/tmp"), oct(1777) ) ) {
             $mess .=
               $this->ERROR("Could not create $Foswiki::cfg{WorkingDir}/tmp");
@@ -55,7 +60,7 @@
 "$Foswiki::cfg{WorkingDir}/work_areas already exists, but is not a directory"
-        elsif ( !mkdir("$Foswiki::cfg{WorkingDir}/work_areas", oct(755)) ) {
+        elsif ( !mkdir(untaint("$Foswiki::cfg{WorkingDir}/work_areas"), oct(755)) ) {
             $mess .= $this->ERROR(
                 "Could not create $Foswiki::cfg{WorkingDir}/work_areas");
@@ -72,7 +77,7 @@

         # Try and move the contents of the old workarea
         my $e =
-          $this->copytree( $existing, "$Foswiki::cfg{WorkingDir}/work_areas" );
+          $this->copytree( untaint($existing), untaint("$Foswiki::cfg{WorkingDir}/work_areas") );
         if ($e) {
             $mess .= $this->ERROR($e);
@@ -93,7 +98,7 @@
 "$Foswiki::cfg{WorkingDir}/registration_approvals already exists, but is not a directory"
-        elsif ( !mkdir("$Foswiki::cfg{WorkingDir}/registration_approvals", oct(755)) ) {
+        elsif ( !mkdir(untaint("$Foswiki::cfg{WorkingDir}/registration_approvals"), oct(755)) ) {
             $mess .= $this->ERROR(
 "Could not create $Foswiki::cfg{WorkingDir}/registration_approvals"

Absloute to relative link converter

# Copyright (c) 2011 Timothe Litt <litt at acm dot org>

# For each file/directory input, convert all absolute symlinks to
# relative links, where possible.  
# Directories are processed recursively.

use warnings;
use strict;

use Cwd qw/realpath/;
use File::Basename;
use File::Find;
use File::Spec;

find( \&process, @ARGV );


sub process {
    return unless( -l );

    my $link = $_;
    my $target = readlink( $link );
    return unless( $target =~ m!^/! );

    $target = realpath( $target );

    # abs2rel works only on paths, so we remove the filename.

    my $rel = File::Spec->abs2rel( dirname( $target ), dirname( $link ) ) .'/' . basename( $target );

    return if( $rel eq $target );

    unlink $link or die "Can't remove link $link: $!\n";
    symlink( $rel, $link ) or die "Can't create new link from $link => $rel: $!\n";

SVN setup

use strict;
use warnings;

my $wiki = lc( $ARGV[0] || 'twiki' );
my $branch = lc( $ARGV[1] || 'trunk' );

my $root = $ARGV[2] || '/home/litt/wikisvn';
my $repo = {
        twiki => '',
        foswiki => '',
die "Unknown wiki $wiki\n" unless( $repo );

chdir "$root/$wiki" or die "Can't chdir $root/$wiki:$!\n";
system( "svn co $repo/$branch/core $branch/core" ); # unless( -d "./$branch/core" );

chdir "$root/$wiki/$branch" or die "Can't chdir $root/$wiki/$branch:$!\n";

open my $man,"<", "core/lib/MANIFEST" or die "core/lib/MANIFEST:$!\n";

while(<$man>) {
#!include ../EditTablePlugin/lib/TWiki/Plugins/EditTablePlugin
  m%^!include\s+\.\./(\w+?)/.*$% or next;
  my $ext = $1;
  next if( $ext eq 'core' );
  system( "svn co $repo/$branch/$ext $ext" );
close $man;

chdir "$root/$wiki/$branch/core" or die "Can't chdir $root/$wiki/$branch/core:$!\n";

if( $wiki eq 'foswiki' ) {
    system( "perl -T default" );
} else {
    system( "perl default" );

selinux (and regular) permissions/ownership fixer - preliminary, still evolving

# Copyright (C) 2011 Timothe Litt <litt at acm dot org>

# Script to fix permissions on a TWiki/Foswiki installation, including selinux contexts
# www-selinux [-v] [-n] [tree ]
#  -v = verbose - chown, chmod and chcon will report every file touched (!)
#  -n = Display actions, but don't make any changes
#  tree = base directory (e.g. ~/httpdocs/twiki)
#    Note that it's PARENT directory's permisssions will also be modified

# Also note that in more recent selinux versions, httpd_sys_script* has merged
# into httpd_sys_*_content.  You'll see that on ls -Z, but the more granular
# names are accepted on input...

# recursion + cd means we need to use an absolute path to ourself.
me=`readlink -ne $0`

# Set permissions

function setperm {
    if [ "$1" = "-R" ]; then r="-R"; shift 1; else r=; fi
    shift 2
    for f in "$@"; do
   if [ ! -e "$f" ]; then continue ; fi
$x      chown $v $r -h $usergrp "$f"
$x      chmod $v $r $perm "$f"
        if [ "$NOSELINUX" = 0 ]; then
$x       chcon $v $r -h $scon "$f"

# Internal dispatch
if [ "$1" = "-fix" ]; then shift 1; setperm "$@" ; exit $?; fi

# -v : list each file
if [ "$1" = "-v" ]; then export v="-v"; shift 1; else export v=; fi

# -n : no action (test)
if [ "$1" = "-n" ]; then export x="echo "; shift 1; else export x=; fi

# directory that's home to the wiki
if [ -z "$tree" ]; then tree="/var/www/servers/twiki" ; fi

# Directory containing wiki directory (/var/www, /var/www/servers, ...)
root=`dirname $tree`
tree=`basename $tree`

# Resolve any symlinks because I'm somewhat paranoid.
# Use with basename of tree to get rid of ./ from recursive call for SVN

root=`readlink -ne $root`
t=`readlink -ne $root/$tree`
tree=`basename $t`

# For an SVN trunk install, use
# ./www-selinux -v twiki/trunk/core
# Note: selinux requires extended attibutes, which are not supported
# on most non-local media.  Run this script on the physical side..
# Httpd probably won't run anyway, so use a phyical disk.

# for webserver
export usergrp="$3"
if [ -z "$usergrp" ]; then usergrp="apache.apache"; fi

# On selinux systems, set security context
# On other systems, do nothing

which selinuxenabled >/dev/null 2>&1 && selinuxenabled
export NOSELINUX="$?"
if [ "$NOSELINUX" = 0 ]; then
    if [ "`id -u`" != "0" ]; then
   echo "Can't change security contexts unless running as root, and won't try"
   export NOSELINUX=1
if ! [ -d $root ]; then
    echo "Creating server root $root"
    mkdir $root || exit $?
# www (or www/servers) holds the wiki root and is NOT owned by apache
$x chown $r $v root.root $root || exit $?
$x chmod $r $v u=rwx,g=rxs,o=x $root || exit $?
if [ "$NOSELINUX" = 0 ]; then
$x    chcon $v system_u:object_r:httpd_sys_content_t:s0 $root

if ! [ -d $root/$tree ]; then
    echo "Creating wiki root $root/$tree"
    mkdir $root/$tree || exit $?
setperm u=rwx,g=rxs,o=x system_u:object_r:httpd_sys_content_t:s0 $root/$tree

cd "$root/$tree" || exit $?

# Here on, find is used to identify files.  This script is called-back on -exec with -fix
# so that we can decide whether selinux contexts need to be handled.  
# In an SVN tree, plugins are "installed" with symlinks.  Thus we never dereference
# symlinks, but do another pass on those directories.  Thus all the checks for dirs that
# may (or may not) exist in extensions.
# All directories: sgid so permissions stick
# Selinux contexts for new files are inherited from directories, so set dirs accordingly
# script- webserver CGI can: exec = execute OK, rw = read and write, ro = read only
echo ""
echo "Processing `pwd`"
echo "Directories"
if [ -d bin ]; then
    echo "bin"
    find bin   \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   -type d -exec $me -fix u=rwx,g=rs,o=x system_u:object_r:httpd_sys_script_exec_t:s0 {} \;
if [ -d data ]; then
    echo "data"
    find data   \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   -type d -exec $me -fix u=rwx,g=rs,o=x system_u:object_r:httpd_sys_script_rw_t:s0 {} \;
if [ -d lib ]; then
    echo "lib"
    find lib    \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   -type d -exec $me -fix u=rwx,g=rs,o=x system_u:object_r:httpd_sys_script_ro_t:s0 {} \;
if [ -d logs ]; then
    echo "logs"
    find logs    \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   -type d -exec $me -fix u=rwx,g=rs,o=x system_u:object_r:httpd_sys_script_rw_t:s0 {} \;
if [ -d locale ]; then
    echo "locale"
    find locale \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   -type d -exec $me -fix u=rwx,g=rs,o=x system_u:object_r:httpd_sys_script_ro_t:s0 {} \;
if [ -d pub ]; then
    echo "pub"
    find pub    \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   -type d -exec $me -fix u=rwx,g=rs,o=x system_u:object_r:httpd_sys_script_rw_t:s0 {} \;
if [ -d templates ]; then
    echo "templates"
    find templates \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   -type d -exec $me -fix u=rwx,g=rs,o=x system_u:object_r:httpd_sys_script_ro_t:s0 {} \;
if [ -d tools ]; then
    echo "tools"
    find tools \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   -type d -exec $me -fix u=rwx,g=rs,o=x system_u:object_r:sbin_t:s0 {} \;
if [ -d working ]; then
    echo "working"
    find working    \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   -type d -exec $me -fix u=rwx,g=rs,o=x system_u:object_r:httpd_sys_script_rw_t:s0 {} \;

# Regular files

# data: txt is writable, rcs is read only, and strays are no access (so they'll be id'd and (re)moved
# Note that security context for rcs is rw so rcs can update

echo "Files"
if [ -d data ]; then
    echo "data - txt"
    find data \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   \( -type f -o -type l \) -name "*.txt" \
   -exec $me -fix u=rw,g=r,o= system_u:object_r:httpd_sys_script_rw_t:s0 {} \;
   echo "data - rcs"
   find data \
       \( ! -path '.svn*' ! -path '*/.svn*' \) \
       \( -type f -o -type l \) -name "*,v" \
       -exec $me -fix u=r,g=r,o= system_u:object_r:httpd_sys_script_rw_t:s0 {} \;
       echo "data - other"
       find data \
      \( ! -path '.svn*' ! -path '*/.svn*' \) \
      \( -type f -o -type l \) ! -name "*.txt" ! -name "*,v" \
      -exec $me -fix u=,g=,o= system_u:object_r:httpd_sys_script_ro_t:s0 {} \;

# pub all but rcs is writable, rcs is read-only
if [ -d pub ]; then
    echo "pub - !rcs"
    find pub \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   \( -type f -o -type l \) ! -name "*,v" \
   -exec $me -fix u=rw,g=r,o= system_u:object_r:httpd_sys_script_rw_t:s0 {} \;
   echo "pub - rcs"
   find pub \
       \( ! -path '.svn*' ! -path '*/.svn*' \) \
       \( -type f -o -type l \) -name "*,v" \
       -exec $me -fix u=r,g=r,o= system_u:object_r:httpd_sys_script_rw_t:s0 {} \;

# lib, locale, templates are read-only
if [ -d lib ]; then
    echo "lib"
    find lib \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   \( -type f -o -type l \)  \
   -exec $me -fix u=r,g=r,o= system_u:object_r:httpd_sys_script_ro_t:s0 {} \;
if [ -d locale ]; then
    echo "locale"
    find locale \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   \( -type f -o -type l \)  \
   -exec $me -fix u=r,g=r,o= system_u:object_r:httpd_sys_script_ro_t:s0 {} \;
if [ -d templates ]; then
    echo "templates"
    find templates \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   \( -type f -o -type l \)  \
   -exec $me -fix u=r,g=r,o= system_u:object_r:httpd_sys_script_ro_t:s0 {} \;

# bin is executable, but logos are not
if [ -d bin ]; then
    echo "bin - ! logos"
    find bin \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   \( -type f -o -type l \) ! -name "logos*" \
   -exec $me -fix u=rx,g=rx,o= system_u:object_r:httpd_sys_script_exec_t:s0 {} \;
   echo "bin/logos"
   find bin \
       \( ! -path '.svn*' ! -path '*/.svn*' \) \
       \( -type f -o -type l \)   -name "logos*" \
       -exec $me -fix u=r,g=r,o= system_u:object_r:httpd_sys_script_ro_t:s0 {} \;

# tools are executable, but not under the webserver
if [ -d tools ]; then
    echo "tools"
    find tools \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   \( -type f -o -type l \) -exec $me -fix u=rx,g=rx,o= system_u:object_r:sbin_t:s0 {} \;

# working is rw
if [ -d working ]; then
    echo "working"
    find working    \
   \( ! -path '.svn*' ! -path '*/.svn*' \) \
   \( -type f -o -type l \) -exec $me -fix u=rw,g=rx,o= system_u:object_r:httpd_sys_script_rw_t:s0 {} \;

# Handle exceptions - we know the locations of these, so setperm is called directly
# (This is the same effect as $me -fix, which find can't do)

echo "exceptions"
# LocalSite.cfg is written by configure

setperm u=rw,g=r,o= system_u:object_r:httpd_sys_script_rw_t:s0 lib/LocalSite.cfg

# .htpasswd contains usernames and passwords, written by registration & change password
setperm u=rw,g=,o=  system_u:object_r:httpd_sys_script_rw_t:s0 data/.htpasswd

# mime.types is read-only data (when used)
setperm u=r,g=r,o= system_u:object_r:httpd_sys_script_ro_t:s0 data/mime.types

# Template files for library pointer and htaccess, the .cfg should be writable for editing, but not by 
# the webserver/scripts
setperm u=rw,g=rw,o= system_u:object_r:httpd_sys_script_ro_t:s0 \
    bin/LocalLib.cfg{,.txt} \
    {bin,working}/.htaccess{,.txt} \
    pub-htaccess.txt \

# Perl require scripts, despite the name
setperm u=r,g=r,o= system_u:object_r:httpd_sys_script_ro_t:s0 bin/setlib.cfg tools/

# READMEs are read-only, but some are served as webpages - find any in add-ons
echo "README etc"
find . \( -type f -o -type l \) \( \
    \( ! -path '.svn*' ! -path '*/.svn*' \) \
       -name 'README' -o -name 'AUTHORS' -o -name 'COPYING' \
    -o -name 'COPYRIGHT' -o -name 'INSTALL.html' -o -name 'readme.txt' \
    -o -name 'LICENSE' -o -name 'index.html' -o -name 'LICENSE' -o -name 'POSTINSTALL' \
    -o -name 'TWikiUpgradeGuide.html' -o -name 'TWikiReleaseNotes*.html' \
    -o -name 'FoswikiUpgradeGuide.html' -o -name 'FoswikiReleaseNotes*.html' \
    \)  \
    -exec $me -fix u=r,g=r,o= system_u:object_r:httpd_sys_content_t:s0 {} \;

# Miscellaneous (template) files accessed as content

setperm u=rw,g=rw,o= system_u:object_r:httpd_sys_content_t:s0 \
    robots.txt \
    root-htaccess.txt \
    subdir-htaccess.txt \
    .htaccess {data,lib,locale,working,templates}.htaccess

# Template httpd config file - N.B. special security context!
setperm u=rw,g=rw,o=  system_u:object_r:httpd_config_t:s0 twiki_httpd_conf.txt foswiki_httpd_conf.txt
echo "Done with $tree"

if [ "$tree" != "core" ]; then

# OK, special case for core. This means (I assume) we are processing a SVN tree
# Since plugin files are symlinked into the core tree, we scan each directory other than core.
# They will have lib/pub/data/tools directories too.  Uggh.

cd $root || exit $?
if [ -n "$v" ]; then v='-v'; fi
if [ -n "$n" ]; then n='-n'; fi

echo "SVN - Running for extensions."

find . -maxdepth 1 ! -name '.svn' -type d ! -name "$tree" -exec $me $v $n {} $root \;

-- TimotheLitt - 14 Jun 2011

I wasn't aware we had hard-coded the workingdir umask to 0755. As for the taint issue, it works fine on my perl 5.10 and 5.12 environments - what perl version are you using? Which OS?

-- PaulHarvey - 14 Jun 2011

Fresh install of fedora 15 under VirtualBox. Started with unformatted disk & fedora .iso, so it's a really fresh install smile

Linux #1 SMP Fri May 27 05:15:53 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

perl 5, version 12, subversion 3 (v5.12.3) built for x86_64-linux-thread-multi

Remember that the value for $Foswiki::cfg{WorkingDir}/tmp just came from a text box in Configure that I changed, so it's tainted. You might not see this if you took defaults, or the next time you run configure because the value would come from a require file, which isn't IO.

FWIW, I pseudo-installed after svn co to a home directory path, but symlink trunk/core there to /var/www/servers/foswiki for the webserver.

Thanks for your help.

-- TimotheLitt - 14 Jun 2011

  • taint issues with working dir. I'm not sure what is going on here. I've tried several times to recreate the taint failures here and it runs cleanly. Started a new install from git checkout, changed working to working2, hit save - everything created fine. Anyway, thanks for the patch. I'll get it applied to the WorkingDir checker.

  • selinux support We've made no attempt to support selinux. I don't know that any of the developers are running it. Not saying that we should or shouldn't support it, but without any developers running it, it makes it tough to test & debug. Are you interested in helping with this?

  • hardcoded permissions Yes they are probably not optimal, we've tried to default to permissions that will work in the majority of cases, and leave it to the admin to further tighten them as needed. Group read/write is pretty critical for anyone running Apache in an suexec environment. The CGI scripts often run under a different user/group than the web server. If we default to restricted group access, it will make foswiki that much harder to get running for the new users.

  • Using S in the permissions I'm not sure what the impact of this would be in some hosted, or suexec environments.

  • validation vs. policy The majority of the checks are warnings. Only when a permission might prevent foswiki from working is it elevated to an error. But even then, configure will save with errors. So nothing is enforced. We don't have a directory permissions "fixup" so configure won't change the directories.

  • default field values aren't being expanded. One I'm looking at right now is {Htpasswd}{FileName}, which shows $Foswiki::cfg{DataDir}/.htpasswd ... correct. Configure shows the exact contents of the fields, and not how they will be interpreted. Otherwise (with the current design) the first save would convert the indirect references to absolute.

The running Foswiki issues a "Load" to interpret the LocalSite.cfg and all of the indirect references are resolved. Configure must show what is actually in the file. A good point though - it would be nice to expand the value maybe in a "Note:" message from a checker for reference.

  • registration I'm not sure what is going on there. Is Javascript enabled in your browser?

It might be easier to solve or at least discuss some of these issues on IRC. I suspect the leanings will be toward permissions that work out-of-the-box for the wide majority of users on a broad cross-section of platforms, and allow sites who have more specialized needs and knowledge to deal with things like selinux one-off.

-- GeorgeClark - 14 Jun 2011

  • Taint: I'm not sure either - I didn't imagine the taint message, and when I went to the line, there was the mkdir. I patched it and hit refresh, the save was accepted. So I assume the diagnosis was right. It was a middle-of-the night fix. It would probably be better to just untaint the config item once.... If I get a chance to try for a reproducer, I will.

  • selinux support It should be supported. It's the default for fedora and I believe others. As soon as I can migrate, I will be running Foswiki under it, and yes, since I have to document the process for my own sanity, I'm happy to supply the docs, scripts and settings. There is a page on installing under selinux - similar to one on twiki. But it's not current, all very manual, and not automated. The main problem is that people tend to work to make the messages go away rather than figure out the right policies... but it's gotten easier.

  • hardcoded permissions The problem is that we don't want people leaving configure with warnings/errors. Your point about cgi vs. shell scripts is valid (at least till the task framework appears :-). Why not simply ask what user/group shell scripts will run under? Then configure can determine whether group, user, or both permissions are required. I've had the webserver run under group with scripts under user as well as the other way round. And sometimes both under one and some other process under the other. Better to ask and do the right tests. Certainly, not wanting world access is common - at least that needs to be configurable. Maximizing the restrictions isn't a good strategy.

  • Using S in the permissions For executables, there would be impact; not suggesting that. For directories it helps. Could be a choice. (I recommend unless there's some hosting restriction.)

  • validation vs. policy There is a script that purports to reset permissions. It suffers from the same policy problems - assuming that world read is OK for sure. This is all exacerbated by the fact that it's not a one-time setup problem. Every upgrade, every extension install has to deal with it.

  • _default field values aren't being expanded. Otherwise (with the current design) the first save would convert the indirect references to absolute. Then the field should show {itemname}, not "$Foswiki::cfg"... That's programmer crypto-speak finding its way into an otherwise elegant GUI.

Agree that expanding into a note would be positive - >>I<< don't know what these variables will expand to without clicking around.

  • registration I'm not sure what is going on there. Is Javascript enabled in your browser? Yes And when passwords are too short I do get the red error text coming and going as expected. But with everything looking OK (to me), no error, grey button. If I click the button, it does turn blue, but it doesn't do the submit. It's very strange. Maybe this is one for IRC.

selinux has become mainstream, not a one-off...and having it work out-of-the box would be a good differentiator from the other wiki.

-- TimotheLitt - 14 Jun 2011

Regarding the registration issue, are you using ShortURLs? The new (trunk-only) UserRegistration (AJAX validation) form doesn't like HTTP redirects in response to its validation requests (which IIRC is a helper topic).

Use firebug's net panel to watch the HTTP requests which go out when you flick between fields or try to submit. You might find there's a 302 redirect (or some other 4xx error).

The task to fix UserRegistration on trunk is Item10817

-- PaulHarvey - 15 Jun 2011

Yes, I decided to use short URLs for this.

Indeeed Item10817 is the registration issue - I was confused. I did set {ScriptUrlPath}{view}, but I set it to /wiki/bin/view (adding /view) rather than /wiki (subtracting /bin). It was early morning, so I was more befuddled than usual, I guess. Thanks.

I also noticed that both "How to activate" e-mails went to me rather than one to me the user and one to me the administrator.

The "registration for" emails properly went to each address (personality?) separately.. Seems like another bug.

Of course, I also noticed that they're not SMIME-signed. I'll see about merging the otherwiki patch I did for that...

-- TimotheLitt - 15 Jun 2011

I'm already working on the S/MIME changes - Item10522 SMIMESupportInMail - it was your feature request. I'm combining them to support SSL, S/MIME, and server time Item10521 and Item10523 Partially committed to trunk.

-- GeorgeClark - 15 Jun 2011

A few other notes: Taint error Babar pointed out, the cycle for configure, is that the Checkers run against the stored config. User input doesn't get checked by the checkers - they are not for input checking, but config file checking. All of the parameters read from the config file should be untainted. So the mystery is even deeper.

hardcoded permissions - The only ones are the working directories. They should exist prior to running configure in which case the hard coded permissions are not used. We ship a README file in each of the directories so expanding the Tar file should create them. Of course the permissions in the tarfile are another issue. The Store (data and pub) structure file permissions are configurable. But it's a hidden expert parameter.

Note that the permissions discussion will become "interesting". There are some strong opinions that configure shouldn't expose "geek" thinks like permissions, etc. Confuses the windows users, etc. Getting the checking and config options in 1.1 was a challenge.

Good point about the $Foswiki::cfg syntax for referencing other config parameters. Unfortunately a number of the config parameters contain perl source. The UI will need a bit of work to hide all this.

-- GeorgeClark - 15 Jun 2011

Re: installation scenarios, and what's appropriate when - we could compile concerns/specs into SecurityChecklists

-- PaulHarvey - 15 Jun 2011

Note: Discussion of S/MIME support implementation details moved to task Item10522 where the work is committed.

-- GeorgeClark - 16 Jun 2011

Hi Timothe,

In the interest of getting a 1.1.4-rc1 out the door (this task is marked release blocker), I have to take your impressions and convert them into actionable items so that we have any hope at all of ever closing this task.

I've identified the following issues which you have raised:
  • Taint error running configure for the first time. Created Item10896 to get this out of the way.
  • Hard-coded oct(755)'s creating missing working directory. A valid complaint, but I don't see an easy fix at first glance (without breaking many out-of-the-box scenarios). Consensus seems to be that we need a smarter configure UI. Let's discuss fruther at SecurityChecklists.
  • Group read/write. Again, not an easy fix. We need a smarter configure UI. SecurityChecklists
  • sgid: again, SecurityChecklists
  • A general observation that we aren't covering SELinux installations well. This is actionable, but we need more specifics, and somebody with the time to dedicate to Foswiki under SELinux. A great way to start would be to establish an SELinux environment with vagrant/chef recipes, perhaps try as a starting point. Then all of us can easily obtain a common SELinux testing environment (and perhaps we need somebody running the nightly builds with SELinux).
  • Default ($computed) values aren't user friendly (show the expanded value somehow). This is actionable, but I don't think it should block 1.1.4 right now (at least, we have more urgent bugfixes we want people to get).
  • Registration, covered in Item10817
  • making absolute symlinks, this is actionable here, but not urgent for 1.1.4
  • S/MIME and E-mail observations, are they covered sufficiently with Item10521 and Item10523?

Does this cover everything? I really appreciate your reflections, as you say you're only a new user once!

I'd like you to consider what specifically we should be addressing in this task, and then re-title it appropriately (or we can simply close this for prosperity/reference, and open more specific tasks from it).

Assigned to minor, as I don't think these remaining issues should block 1.1.4 (but maybe it could block 1.1.5)

-- PaulHarvey - 18 Jun 2011

Created Item10902 - Configure should show expanded values of fields.

-- GeorgeClark - 19 Jun 2011

I've been stretched rather thin recently, sorry to be so slow to respond.

I'm OK with splitting this up; I think that's the way to go. I thought it better to capture the experience in one place, as I could do that while working. Breaking it up at the time would have required too much thought (while fighting the install). . I have some updates on the security items, will add remarks in security checklists.

There is one item you missed - or maybe it moved with the S/MIME comments. In any case, where configure wants files/file paths, it's really annoying to locate them externally. It would be nice if there was a browser dialog for this. E.g. similar to upload, but initially rooted at the Foswiki root. So one could just click on the "working", "lib", or "bin" directories, or naviage to where the X.509 certificates for S/Mime are and click on them. Seems like it could be done with a bit of ajax magic... Certainly not a release blocker, but a normal priority suggestion.

We can close this summary topic.

-- TimotheLitt - 28 Jun 2011

Closed this as a Duplicate - The identified issues are covered in separate toics.

-- GeorgeClark - 01 Oct 2011

Added Item11160 to cover the request for Ajax magic.

-- GeorgeClark - 01 Oct 2011

ItemTemplate edit

Summary Out-of-the-box problems in configure
ReportedBy TimotheLitt
Codebase 1.1.3, trunk
SVN Range
AppliesTo Engine
Priority Urgent
CurrentState Duplicate
TargetRelease minor
ReleasedIn n/a
Topic revision: r17 - 01 Oct 2011, GeorgeClark - This page was cached on 06 Jun 2020 - 08:09.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy