Last modified: 2012-06-17 23:43:57 UTC
in <1.17 it put it in config/LocalSettings.php and asked you to remove it. My search-foo isn't coming up with a discussion on why this was changed. In 1.17 it's asking you to download a file, use some kind of ftp/webftp client and upload the file. I am well aware on some setups php cannot write to the local filesystem. The solution seems simple, if you can write to the filesystem, then generate the file there and offer the download as an optional alternative to moving it. Otherwise, offer it up for download per 1.17. This will be more in line with any kind of 'auto-install', 'auto-upgrade', 'web-configure', 'ext-download', 'ext-install', 'ext-upgrade' feature we may get in the future. And dare I say, ala wordpress. And for documentation's sake, I'll note here that I understand putting it in Config/, you have no real guarantee that the web user is the administrator, so you're asking some kind of further interaction to ensure the settings saved are indeed those of the owner of the website.
This was done on purpose, having the webserver write the file is unsafe.
I'm sorry if this is a stupid question, but could you please provide more clarification? How is it unsafe? And how does this affect efforts to make auto-download/installers for extensions of MediaWiki?
Having the webserver write the file means that it's created as webserver writable, and people often forget to fix that so it's not webserver writable. The result is numerous MediaWiki installs with a webserver writable php file that's now the easiest target to attack a wiki with if you find a vulnerability in the webserver or are on a server with separate safe user accounts, but a shared webserver user. I know we've expressed desire to improve our system for configuring and installing extensions, and checking for updates. But I don't believe we ever planned to have MediaWiki go and download php files from some source on the internet and drop it right into it's own install. That kind of practice is horribly insecure, that's the kind of thing that creates critical security vulnerabilities. By the way, last time I checked WordPress' updater seamed to like using FTP rather than using webserver writable files. As for config, trust me, if we add in the ability to configure MediaWiki from the web side, we won't be doing that by writing to a php file that could be used as an attack vector, or even kill the wiki if you accidentally manage to insert some invalid php into it.
Wordpress uses a fallback chain. If it can write directly to the filesystem, it uses that. After that it tries to do various ftp access. Then shell access. Then says you're on your own (do it yourself). And in the case of wordpress you definitely just search for a plugin/extension, and click 'install'. The whole "but it's untrusted php!" is kind of a moot point, you're already asking the user to go download that same php and install it, untrusted and all. I see your point about the whole Web config angle, a mysql table or something would be infinitely better even if for now we are stuck to Extension:Configure. I have heard of bugs mentioning rewrite incoming though... For the problem with the webserver, would it be possible to have the webserver change the owner/perms to the owner/perms of all the other files? To 'gift' the files if you will. I'm not well versed in this on windows or linux. Because of Daniel's point on a web config not needing to touch the filesystem, I'll agree and say this isn't really a problem that needs solving. Thanks for the clarification!
Wait, doesn't PHP have chown[1] and chmod[2]? If written correctly, surely they should compensate for the incorrect fixed LocalSettings.php file in most cases. Or in addition add a button that writes the LocalSettings.php file on the webserver while warning the user about its issues. [1] http://php.net/chown [2] http://php.net/chmod
(In reply to comment #5) > Wait, doesn't PHP have chown[1] and chmod[2]? If written correctly, surely > they should compensate for the incorrect fixed LocalSettings.php file in most > cases. > > Or in addition add a button that writes the LocalSettings.php file on the > webserver while warning the user about its issues. > > [1] http://php.net/chown > [2] http://php.net/chmod "Only the superuser may change the owner of a file." I'm pretty sure 99.999999999999% of us don't run our php processes with root permissions.
(In reply to comment #6) > "Only the superuser may change the owner of a file." > > I'm pretty sure 99.999999999999% of us don't run our php processes with root > permissions. All right, that's true. And I would hardly recommend anyone to run PHP under root. I was just under the impression that you could give away your files without the need to be root. However, I still strongly disagree with the way you are handling this issue by keeping the user out of the know. The user expects the system to write the file itself, and I am certain more complaints will spring up as 1.17 become more popular. The installer fails to explain why the functionality has been removed, a functionality people have come to expect of installers like that. Furthermore, to warn users of such issues would probably make them inclined to fix problems with perhaps other installations of MediaWiki (<1.17) and/or projects that had the same installation behaviour. Why at the very least not tell the users what's going on? I certainly was confused why I was forced to download the LocalSettings.php all of the sudden. I assumed at the time it was because I was using a non-release and the functionality wasn't done.
Svip is right in that there definitely was a lack of communication with our users here, and clarification /somewhere/ (a bit hence this bug) is needed.
22:33 < jigp> when i upload a file it says scp: /var/www/html/mediawiki/mediawiki-1.17.0/resources/LocalSettings.php: Permission denied. im using winscp windowsxp.im ticking all the tabs of winscp and i found SSL check.but when i try to upload again, i still received errors of permision 22:33 < finlay> jigp: make sure you have permission to write to that folder 22:34 < jigp> ok thanks 22:34 < finlay> jigp: you may be using the wrong user to upload 22:34 < finlay> or the folder you are trying to upload to may be owned by another user 22:34 < jigp> no im using a sudo account 22:34 < jigp> finlay im in the sudo member 22:35 < finlay> try uploading a different file to the same directory 22:35 < Dantman> jigp, If you're talking about being someone other than root that has sudo permissions that doesn't help 22:35 < finlay> and is there already a LocalSettings.php file there? 22:35 < Dantman> ...sudo permissions only apply if you actually execute something with sudi 22:35 < Dantman> sudo* 22:35 < Dantman> And that doesn't happen from most upload protocols 22:36 < Dantman> Even scp doesn't do that 22:36 < jigp> finlay : no LocalSetting.php thats why i want to upload it in the /var/www/html/mediawiki folder 22:37 < jigp> finlay this is the reply of the mediawiki when i install using browser 22:37 < jigp> Congratulations! You have successfully installed MediaWiki. 22:37 < finlay> how did you get the mediawiki folder there? 22:37 < gicode> jigp: Upload it to your home folder and sudo mv it over 22:37 < jigp> The installer has generated a LocalSettings.php file. It contains all your configuration. 22:37 < jigp> gicode : im using winxp with winscp 22:37 < jigp> You will need to download it and put it in the base of your wiki installation (the same directory as index.php). The download should have started automatically. 22:37 < jigp> thats the reply 22:38 < jigp> i will set Chroot 755 permissions? 22:38 < jigp> i tried $ chroot 755 22:38 < jigp> but invalid command 22:38 < jigp> even chroot 755 /var/www/html/mediawiki 22:39 < gicode> jigp: sudo chmod go+w /var/www/html/mediawiki 22:39 < gicode> then upload and change it back with sudo chmod go-w /var/www/html/mediawiki 22:40 < finlay> my friend has the right of it I'm afraid 22:40 < jigp> same error after i "sudo chmod go+w /var/www/html/mediawiki 22:40 < jigp> scp: /var/www/html/mediawiki/mediawiki-1.17.0/LocalSettings.php: Permission denied 22:41 < finlay> (ironically I bet you his webserver could of written the file) 22:41 < jigp> gicode : ill include mediawiki-1.17.0 i guess? 22:41 < finlay> his/her 22:41 < jigp> sudo chmod go+w /var/www/html/mediawiki/mediawiki-1.17.0 22:41 < finlay> yes 22:41 < gicode> finlay: indeed 22:42 < finlay> jigp: worked? 22:42 < jigp> perfect!!!! 22:42 < jigp> thank you so much! 22:42 < jigp> sudo chmod go+w /var/www/html/mediawiki/mediawiki-1.17.0 did the trict 22:41 < finlay> (ironically I bet you his webserver could of written the file) 22:41 < gicode> finlay: indeed maybe have a link (with a big warning, javascript popup etc) to have the webserver write it, if we detect we can. Given my experiences in forum installation forums, the above is a common sight of the nightmare of permissions. Of course you wonder how they ever got the package files there... but we will never know.
(In reply to comment #9) > maybe have a link (with a big warning, javascript popup etc) to have the > webserver write it, if we detect we can. Given my experiences in forum > installation forums, the above is a common sight of the nightmare of > permissions. Of course you wonder how they ever got the package files there... > but we will never know. Really? My memories of installation nightmares have been with people not having made things webserver writable trying to install, getting to a point where the db and everything was setup, it trying to write the config file, failing, then leaving the user to have to cleanup and restart the whole process. That... or if the system had decent writable checks being forced to change the permission of folder after folder one by one, only to find when I return to the installer I have even more things it's telling me I need to change the permissions of.
(In reply to comment #10) > (In reply to comment #9) > > maybe have a link (with a big warning, javascript popup etc) to have the > > webserver write it, if we detect we can. Given my experiences in forum > > installation forums, the above is a common sight of the nightmare of > > permissions. Of course you wonder how they ever got the package files there... > > but we will never know. > > Really? My memories of installation nightmares have been with people not having > made things webserver writable trying to install, getting to a point where the > db and everything was setup, it trying to write the config file, failing, then > leaving the user to have to cleanup and restart the whole process. > That... or if the system had decent writable checks being forced to change the > permission of folder after folder one by one, only to find when I return to the > installer I have even more things it's telling me I need to change the > permissions of. I forgot that this is impossible to check for in PHP. My apologies. Listen, for *most parts* people would prefer this option to be available. I can handle having to download my LocalSettings.php and whatnot, but I also doubt that most people are like me. An alternative alternative could be creating the installation script as a command line script, then surely the user would be required to be logged in as themselves and then it could print it (and even if the user lacked write-access in this instance, it could always send it to the user's homedir and inform them of the new location). You really seem to be steering up a lot of non-issue bullshit in your refusal to fix this problem.
*** Bug 37664 has been marked as a duplicate of this bug. ***
