TYPO3 Core

Yes, perhaps installer should check for correct permissions and emit a warning for insecure ones like these.

I just found the reason for the world-writeable files and directories.

zipinfo dummy-3.7.0.zip  |grep rw.rw
shows the mentioned files and directories. So this is a out-of-the-box problem...

This is definitely an issue, although 777 is unfortunately even recommended in the T3 book. Making stuff world-writable is the easiest way to avoid newbies' complaints on the list.
I find your workaround a bit harsh, in shared environments chmod -R o-w is enough.
Ingmar, Stucki, do we have a reason for world writable files?

Yes you are probably right. We did change the default permissions from 755 to 777 before releasing 3.6.0 I think. The reason was that (according to feedback) many people had problems with changing permissions etc.

Our idea is that if you don't care about permissions and security, then you just want to untar that file and start using it. However if you DO CARE about security, then you will read the INSTALL.txt file (hopefully!) where everything is written in detail.

So I think it's quite ok to keep it that way.

- michael

Stucki, MS did that before and they got bashed for it. They deserved this bashing and changed. Patches of IE and for XP (SP2!) tighten the security even if it may imposes some surprises to the unexpecting users.

777 is a big nono for a default installation. I suggest 775 which is a bit moe secure and should still work for a usual setup.

MS did that before and they got bashed for it. They deserved this bashing and
changed.

Right! I don't like MS at all, but this time they did something which is "a good idea" [TM]. Maybe there's still some hope for MS... ;-)
(But my best argument is still that Linux had this "good idea" from the beginning ;-)

OK, back to the topic of this bug...

I suggest 775 which is a bit moe secure and should still work for a usual setup.

I don't know if 775 really helps ;-)

The mass hosters I know include all users in a group "ftponly", so with group write access nearly all (relevant) users will still have write access.
Additionally 775 usually doesn't allow wwwrun to write into these files/dirs because wwwrun isn't in the ftponly group.

My suggestion: use 755 as default rights (like in 3.5) and add a big, red-colored message to the installer ;-) (or is the message already there? I didn't check a long time since I use a self-written script to install Typo3)

BTW: If someone reports problems because of missing write access for wwwrun, first post the relevant FAQ link. This doesn't need much time and usually helps the users.

World-writable is definitely not a good idea, this should be changed.

Group-writable isn't that bad, if you set aside the mass-hosting scenario described above - we always have o=user,g=www-data and this runs fine.

But it may be even better to remove the group write right as well. People should have to read the (short) readme file, and it tells them how to set permissions. Those who want to try TYPO3 for the first time often do this on a windows machine, those who want to install on a 'real' host usually are sure they want this - they should be firced to set up a secure system.

If attacks on a noticeable amount of TYPO3 setups are done and succeed because of this rights thing, this will fall back on us, not on the users.

OK but we could at least help those users with a handy shell script that checks for possibilities and sets the permission as good as possible.

Or do you think should let them completely alone when they don't know about chmod and open-basedir (which could be very important here!)?

It's fine for me to change this back starting with 3.8.

Thanks to the user bzoltz who just volunteered to point all those users to the FAQ every time they post such a problem (it doesn't need much time... ;o))

- OK but we could at least help those users with a handy shell
script that checks for possibilities and sets the permission as
good as possible.

I don't know if a shell script would really help. Many users (especially those who would need the script ;-) don't have shell access to the webserver.

Additionally: what should the shell script do? Blindly running chmod 777 isn't a good idea; chown can't be done by a normal user (only root), and you don't know if username should be "wwwrun" or "httpd" or ...

Or do you think should let them completely alone when they don't
know about chmod and open-basedir (which could be very important
here!)?

Add more detailed error messages. I just did a new installation, run chmod go-w -R and got the message "/path/to/dummy-3.7.0/typo3conf/localconf.php is not writable!".

If you add a documentation link to this (explaining chmod / chown and open_basedir), this first problem should be solved. The "better" error message would be: "$file not writeable. See ...... for help."
(...... should be a link to documentation explaining chmod/chown and open_basedir).

The other files and directories that need to be writeable for wwwrun are listed after the 1-2-3 installation is done and you click on the "Continue to configure TYPO3 (Recommended)" and then the "1. Basic configuration" link. No problem so far, but again a documentation link would be more useful than just "The directory xy must be writeable!"

And: Yes, open_basedir is very important here. Unfortunally, it must be set for all users on a server by the admin. Hope he does, but don't rely on it ;-)

Thanks to the user bzoltz who just volunteered to point all those
users to the FAQ every time they post such a problem (it doesn't
need much time... ;o))

What a luck that this was bzoltz and not me ;-))

To make the "BTW" from my last comment clear:
- send somebody a FAQ link: around 30 seconds, good answer quality
since the FAQ text is checked by many people.
- write a complete answer: some minutes, possibly not-so-good answer
quality - you could miss something or just include a typo in a
command.
Trust me - I'm an author of the german SuSE Linux FAQ and know it ;-)

Done. The 3.8.0 packages have 755 permissions for all directories and 644 for all files (including fileadmin, etc.).