Not a bug Attachment files not being deleted & improper chmod

[Floren]

Hi Mike,

I did a quick test related to image deletion and every time I hard delete a post, the attachment info is deleted from tab,e but the physical file remains on the server. Is this the intended behavior? Because that could generate a lot of orphan files which are not visible into Attachment Browser.

Another important point related to attachments is the chmod condition for a writable dir/file. I see that you use the chmodWritableValue into configuration. Personally, I would extend it to match the proper values for both dirs and files.
Find:

if (XenForo_Application::isRegistered('config'))
{
	$chmod = XenForo_Application::get('config')->chmodWritableValue;
	if ($chmod)
	{
		self::$_chmodDirectory = XenForo_Application::get('config')->chmodWritableValue | 0111;
		self::$_chmodFile = XenForo_Application::get('config')->chmodWritableValue;
	}
}

Replace with:

if (XenForo_Application::isRegistered('config'))
{
	if ((bool) XenForo_Application::get('config')->chmodDirectoryValue)
	{
		self::$_chmodDirectory = XenForo_Application::get('config')->chmodDirectoryValue;
	}
	if ((bool) self::$_chmodDirectory && (bool) XenForo_Application::get('config')->chmodFileValue)
	{
		self::$_chmodFile = XenForo_Application::get('config')->chmodFileValue;
	}
}

 

[Floren]

Note to self, the above new values should be also defined into loadDefaultConfig().

 

[Paul B]

The files are removed via a routine cron task, not immediately.

 

[Floren]

Thanks Brogan, I did not know.
Let's hope Mike addresses the second issue, as in my server all writable files are chmod'ed 0755 which is a big security risk. I use the above values because I do not want to have my attachment directories set to 0777 and files to 0666.

Disabling PHP for a specific directory is not a solution, when you can fix the problem at its root.

 

[mrGTB]

I have to agree about the chmod thing, I think it's a bit of mess how it's all getting done right now and you can see from quite a few posts listed here that it's causing problems for many people, it did with me also before. I really don't get why I can install vBulletin, MyBB and a host of other forum software used in the past and never come across this chmod issue XenForo has with making directories and some files 777 on install, or when uploading some files or images e.t.c. It should be left to the server to set it's own permissions based on how it's been configured to deal with chmod.

At the worst, don't chmod anything to 777 and list what needs to be done manually if still required by some server host. But doing it auto when most server host don't need, or even allow 777 to be used is just crazy in my book. Your creating unnecessary tech support problems for yourselves and for people installing it.

 

[Floren]

I have to agree about the chmod thing, I think it's a bit of mess.

Personally I think the check is very well thought, better than any other systems out there. The only missing bit is defining a specific chmod value for those who want to tune everything to their taste. Right now you can only set the files to 0644 or 0666, not 0640 (for example). And is good that Xenforo does a file check before you install the software, so you don't wonder why files are not uploaded properly. Saving CSS as files in vBulletin rings a bell?

 

[mrGTB]

Can't agree with you and that one, not from my own experience before I'm afraid well highlighted here in another thread. Folders and Files given 777 on install by default that my shared hosting didn't allow to be used causing 500 server errors to get served. In the end I had to edit the config file like Mike suggested as a work around, adding code to make sure everything was given 644 instead, then having to manually change chmod on folders from 644 to 755. I couldn't use 755 in config, otherwise all files would be given that same chmod permission as well requiring 644. A much bigger job changing things if doing it that way.

Really, all that should not be necessary and I've never had to do with any other software used to date. Usually on other software I've used nothing gets chmod by it during installation, folders are given 755 and files 644 by server itself during FTP uploading. If something needs to be changed during the running of the installation itself, like another chmod permission value (other than 777) needed, such as (666) to write to a config file. The server itself sets it to suit accordingly itself without no manual chmod from me taking place. I've never had to do any "manual chmod" at all.

The problem is one that XenForo is forcing it's own chmod values on folders and files, rather than letting the server do it auto. That the biggest issue and it setting some as 777, or putting wrong permission on files that should be nothing but 644. I saw HTML index files given 777 permission, that's wrong for a start, same with files I spotted showing 777 that didn't even need writing too, just general PHP files requiring 644 again.

 

[Floren]

I don't think so. FTP user permissions and web server user permissions are a totally different thing. By default a FTP user is assigned by root admin with very little perms on the system. Usually they are restricted to the /home directory, permissions wise. This is how Unix works, is not something invented by your host. So by default the FTP user (you) does not have the same perms as the web server user (apache, nginx etc.) which is always the winner. If you FTP files into a dir, you need to make sure those files are then owned by the web server user in order to be able to write to them properly.

I've used nothing gets chmod by it during installation, folders are given 755 and files 644 by server itself during FTP uploading.

I never chmoded any dirs either, but I did owned them by the web server user. Is all you have to do.

 

[shawn]

I really don't get why I can install vBulletin, MyBB and a host of other forum software used in the past and never come across this chmod issue

Because you were storing files in the database. If you'd put them in the file system, you would have run into the same problem.

 

[mrGTB]

Because you were storing files in the database. If you'd put them in the file system, you would have run into the same problem.

No, I moved files to storage one level above root when using vBulletin to lessen the size of the database. Same with album uploads, and other upload types in vBulletin 3 that can use folder storage instead of in database. First thing I do that when setting things up, same with error logs you can write to folders in vB3. Being on shared hosting that can limit the database size you are able to upload and restore, meant that's something I need to do for obvious reasons. Instead backing up Files, Albums e.t.c via FTP instead.

As for MyBB, it uploads all Avatars to a folder by default, not in the database.

 

[shawn]

And... if your folder was owned by mrGTB:mrGTB and set 755/644/etc, your apache:web users wouldn't be allowed to write there. Posix permissions are posix permissions... what forum software you're using has no effect on it.

 

[mrGTB]

Any, I don't chmod anything manual. If using MyBB and it uploads an avatar to the folder, folder is still 755 permission. It was the same with IPB before when I used that, they tell you to chmod some folders to 777 but never did because it's not needed and everything worked fine, even permission checker in IPB after reported everything that should be writeable was, although 777 was used on nothing. Same with MyBB permission checker, reports all is OK but 777 is never used.

Maybe that's the way my server was configured, to still write to folders without 777 needed. Even XenForo has no issues at all working for me without 777 used on anything. But if I use 777 on folders, 500 server error pages will happen.