Using File Permissions brings down entire site?

[Angelina Belle]

I was using File Permissions to try to fix file permissions so I could install packages.

I was working on a fresh install of SMF 2.0RC3 in a subdirectory of  my site --- http://rockhallsailingclub.org/smf2test
I'm using 1and1 shared hosting.

The file permission changes didn't seem to be happening, though wasn't getting any error messages from SMF.
I had a look at it from the command-line FTP client, and it looked like quote CHMOD has been disabled on my ftp server.
That seemed strange.

I then attempted to change the permissions on /smf2test/.htaccess to 0755 just to make sure it really wasn't working.
Suddenly, the entire website is down -- 403 errors on http:/index.php
And, to top it all off, my FTP password stopped working! I couldn't log in because I had no permission to view the root directory.

What happened? What could SMF have done that would have caused the top directory's permissions to go bad?

[Kill Em All]

Your website seems to be working fine to me. As a general rule, all folders should be 755 and all files should be 644.

[Angelina Belle]

It's all better now.  The master acount owner fixed the permission.

I am still wondering how using SMF's File PERMISSIONS in a subdirectory caused permissions to be removed from the FTP login root down.
That seems like a bug.

From now on, if I need to change permissions, I'm doing it by hand.
One file at a time.

[Kill Em All]

That sounds more like a problem with the program you are using, not SMF. I don't think SMF would do that.

I am going to mark the topic solved, please feel free to unmark it solved if you have further questions.

[Angelina Belle]

Actually, I think SMF DID that.  I didn't believe it the first time it happened.  So I tried again another day. Same thing happened -- try to change the permission on a file in the SMF root, and the permissions for the entire site went to 000.

I wonder if the master account owner can change CHOWN the ftp login directory, then CHMOD to 775, to prevent this accident from ever happening again.

Nobody else has ever seen this behavior?

[Kill Em All]

Unfortunately, I don't have this issue.

When you tried accessing your site, did any errors come up? Can you copy and paste the exact error, also check your admin error log.

[ActivePatriot]

I had the same problem recently.

I did not have the problem before until I switched webhosting.

I also had to go through the host to get permissions changed so that I could view my site again.

It is the webhost.  On some shared hosts, they won't let you change permissions through scripts (SMF being scripts, I guess).

Smaller mods I have no problem, if I install larger mods, I go through the webhost's CPanel (not SMF) to change permissions to avoid the problem your talking about.

[Angelina Belle]

The account I am using is a sub-account, so the master account owner was able to fix the root-level permission.
I don't have cpanel access. Only the masteraccount holder has that.

I have never had this trouble with SMF 1.1.11. Only with SMF 2.0.

I still think this is, at best, a very undesireable feature. What was SMF doing in the ftp login root when I told it to do a CHMOD on a single file in a subdirectory?
I can chmod all day long using command-line FTP and not run into this problem.
As long as I don't go to the login root and "CHMOD 000 ."

I'm thinking that, in some unexpected case, that is exactly what SMF is doing.

[Kill Em All]

It is the webhost.  On some shared hosts, they won't let you change permissions through scripts (SMF being scripts, I guess).

I believe that is why you were having troubles, it is just helpful to have that there incase you don't know how to change the permissions and it just gives a "noob" friendly way.

[Angelina Belle]

The SMF chmod feature just uses the FTP client.
I would think that, as far as the host is concerned, it would look like any other FTP access.
But I am not sure.

[Kill Em All]

No, because SMF is a script on the web server. It acts like a FTP client I guess you can say but it isn't a FTP client at all. All it does is CHMOD the folders.

[Angelina Belle]

Doesn't the script actually call an FTP client?

[Kill Em All]

Taking a quick look at the Packages.php file, it doesn't necessarily call in a FTP client. Just attempts to change its own file permissions in its own root directory.

I'll see if someone else can explain this better.

[Kill Em All]

If SMF has to use FTP, that means that PHP isn't running as the same user that owns the files, so it has to use FTP to adjust permissions, which means not using php chmod.

If SMF does not have to use ftp (in the case of the server having suExec or suPHP), then it uses php's chmod because php will be running as the user who owns the files and therefore (in theory) control their permissions.

So yes, it could be using FTP, but if suExec or suPHP is running, then it won't be using FTP to change the settings. Check to see if either of those are installed on your server with your host.

[Norv]

Moved to Bug reports, though it's not yet obvious to me whether there's a bug here.
Unfortunately, I don't seem to have means to replicate it. It sounds more like a server configuration problem of some kind in any case, anyway a phpinfo() file may be useful.

[Arantor]

If the .htaccess file is renamed to something else, does it then work?

I get the feeling the error is related to permissions on .htaccess blocking everything else.

[Angelina Belle]

Thanks for the information, and for considering the possible causes.

I am not likely to try the experiment again, as it does chmod 0 on /, I don't have the keys to fix it, and the master account owner is not interested in the experiment.

I just have an ftp sub-account.

Just FYI, I have attached .htaccess for the website root and the test forum root

phpinfo, website (and ftp) root http://rockhallsailingclub.org/bobo.php
phpinfo, test forum: http://rockhallsailingclub.org/smf2test/bobo.php

[kat]

Just a thought, here...


Some hosts don't, in truth, give you full "ownership" of your files.


Could that be what's happening, here?

[Angelina Belle]

Some hosts don't, in truth, give you full "ownership" of your files.
Could that be what's happening, here?

The host is 1&1. I don't have access to the 1&1 control panel on this account.
When I do a DIR via command-line FTP, it looks like . and everything below it belongs to the ftp account user.
I was able to chmod 000 / (or maybe it was cd / followed by chmod 000 . ?)
And I did need to give SMF my FTP username/password to accomplish that.
After that, of course, I was out of luck, and needed the main account owner to rescue me with chmod on the ftp root.

So I was assuming that it all happened via the FTP SERVER, regardless of whether a bonafied ftp client was involved. I did assume, after skimming through the code, that an ftp client was also involved.  But I don't know.

[kat]

It's one of those oddities, where one term, "Owndership" can mean different things.


You may have access to files. You may be able to CHMOD them.


But, your host still has "Ownership" of them all, unless he hands that over to you.


Some hosts do, by default. Others, you have to threaten them with a nuking to get them to do it.


Weird, huh?

[Angelina Belle]

I guess sometimes UNIX is not UNIX, and the owner shown in DIR is not the owner.
That is weird.

[kat]

"Weird" describes the entire world of the internet, rather well.

[Joshua Dickerson]

Is this actually a bug? Still happening?

[Illori]

i have seen on my server [before moved to another server by host but not tested after move] some mods cause the main home/<username> folder to have incorrect chmod applied on a server that requires chmod 755 on folders. i had spoken to norv about it at the time and he said he had heard others have similar issues but no idea what caused it.

[Angelina Belle]

If anyone is willing to loan me a 1 and 1 account, I am willing to do the experiment.
I am not willing to do this on my live forum.

phpinfo tells me: SERVER_SOFTWARE Apache and also  Server API CGI , so I know that I've got apache running php in Suexec mode.

I am pretty sure 1and1 has this set up correctly.  They've been doing this for a while, and they seem to have a good reputation for setting their servers up properly.

[Trekkie101]

I can't get this to 000 anything on my cPanel host, sadly no 1&1 account to try with. Marking as unable to reproduce, someone open a new bug report if it persists.

[Angelina Belle]

Might as well.  Nobody can reproduce the error, for lack of an appropriate testing platform.

I really do wish I could find another 1&1 account to test this on.

[Arantor]

Closing this, retracking centrally under https://github.com/SimpleMachines/SMF2.1/issues/1276

That report links back here and means that when we tackle it, we can find all the relevant information easily.