[phpBB] Discussion about 'multisite'

J.M.Roth jmroth at iip.lu
Thu Mar 11 18:38:06 CET 2010


On 3/11/2010 5:17 PM, David Prévot wrote:
>> As noted in #437836 I'm asking for developer feedback here.
> Some one responded quickly did you ping them elsewhere ?

No, not at all...

> So it seems. I find it a pity not to be concern about repeated code,
> especially for web application, but once we have some thing effective,
> maybe we can try to come back to them and propose them our patches...

I stopped patching at some point and included some workarounds in
README.multiboard. This issue is more complicated than it seems at first
glance.

>> We could at least include the install folder with a random suffix, e.g.
>> install.5Tp7Jg and hope this will not be a source for brute force
>> attempts to access that folder.
> 
> I don't believe it would be safe to count on some name obfuscation for
> security purpose. If some install script is useful, it should be
> provided, but if they are security flows, it might need a second thought...

Maybe we could also just put it somewhere outside the web root, like it
was proposed in one of the bug reports. Then at least people have it.
I tried running the updater manually, and it bailed out at me (something
with "module not found"). I will have to check what's going on; anyway
it seems it is quite a mess. (Or doesn't like some customizations we make.)

>> Is anything speaking against what I proposed in #447542, i.e. setting
>> the dirs in /var/lib to 1753 (i.e. rwxr-x-wt, root:www-data).
> 
> I don't get why they need to be world writable : if the web server is
> executed by www-data (or a user in www-data group), www-data group
> should be able to read (and write if necessary), but if the web server
> is executed by someone else, making a directory readable by the www-data
> group (and not world readable) is pointless.

The sticky bit (t) on the directory means that the owner of anything put
into it becomes the one who put it in there. Making the directory not
world readable means noone can list it. Since the execute bit is still
there (for world, otherwise it would say "T" and not "t"), the one who
knows the name of the file (and owns it, depending on the permissions
/of the file/) can still access it. Just like your everyday temp
directory, except that here noone is allowed list it.

This works even when the webserver writes as 'www-data' into the
directory, although then, everyone can read everything - if they know
the filename.

The group could also be root, that's true. The important part are the
"-wt" permissions for other. Oh and actually I'm rather using 1733, that
is rwx-wx-wt, but this doesn't matter much.

> I use an other approach : creation of the necessary directory when
> activating a new forum, and give them drwxrws--- rights
> (www-data:$GROUP) where www-data is member of $GROUP, and the designed
> webmasters are members of $GROUP too (in purpose of local maintenance,
> but it might not be needed).

The problem with that approach is that everyone would still be allowed
to read everyone else's files inside that directory, since all new files
would automatically inherit the www-data GID.

Let me go a little further up the hosting tree:
- apache with modphp (everything runs as www-data)
- apache with php-cgi (apache runs as www-data, php can run as any user)

I have a setup using suexec and php-cgis, meaning whatever is dynamic
(php) is run by the individual user, let's call him webXX_admin:webXX.
The static content (e.g. x.html) of each user is still read by
www-data:www-data.

In your case, webXX_admin (in fact, any(!) user) would have to be member
of the www-data group (to be able to read his files again after writing
them), which results in what I said before.
In my case, the www-data /user/ is member of each webXX /group/ it needs
to access, meaning neither the webserver nor any other user can access
files they should not.

>> That would make the additional sites easier to setup (less steps).
>> Or should this directory creation be combined with the problem above by
>> maybe creating a script to give the system new info about the new site:
>> - database name
>> - database prefix
>> - site name = cache folder path etc.
> 
> I made a quirty script for this purpose, I can post it if it is of
> interest, or try to adapt it and make it less dirty when we agree about
> the multiboard method.

As a matter of fact I have now some code in
/usr/share/phpbb3/www/config.php that creates the site name ($url_forum)
automatically (from host name, port and path). No need anymore to
specify it somewhere.

If you have a script, why not include it, although for the average user
who knows what they are doing (and I hope they are when dealing with
stuff like this), a good README and example configs should be enough,
shouldn't it?

Greetings,
JM




More information about the phpBB-l mailing list