File Permission Failure

[jcdubois]

Can somebody explain to me the logic behind TimeTrex checking for write permissions on files and folders that have absolutely nothing to do with it?

My installation of TT is in its own account, at the root of the public web folder. Due to the way my host sets up their accounts, TT fails to install because it doesn't have write permission on an .htaccess file located in a stats folder that is required to be in the public web folder. (The owner of this file is root, for the record.)

In order to get TT working, I have to go in and bypass the file permissions check and, subsequently, the file integrity check in the installer, meaning A) I'm losing access to functionality that is absolutely important from a security standpoint and B) I can't let the site auto-update because on update the bypass is overwritten and the install fails again.

Setting aside for a moment the annoying fact that my host requires files and folders in my web root that I didn't put there... why is TT even checking these files for write permission? I'd hope it would never have reason to screw around with files that have nothing to do with it...

With information from another thread I've disabled auto-updating, but I'd like to be able to re-enable it and save the extra work of manually updating.

[shaunw]

Unfortunately its impossible to provide a specific list of files that TimeTrex needs to check permissions on, as in some cases directories/files may exist that it doesn't know about but will still need access to, so because of that it simply checks all files in the root TimeTrex directory instead.

Keep in mind though that TimeTrex doesn't support shared hosting environments (for many reasons, the issue you are running into is just one of them), so this is normally not an issue when you have full control over the hosting environment.

[jcdubois]

Ok, but then how are you validating file integrity in the next step, if you have no way of knowing what all files you might have on installation? If TT doesn't know about a file, how can it possibly use it?

Please forgive me, I'm being mildly sarcastic, but that's because I'm having trouble reconciling the response with the use case. This is an installer/updater for your software - shouldn't the only files and folders you need to worry about be those that are actually part of TT, rather than any additional files your end-user may have chosen to install? Even then, there's no way to provide a list of folders that actually belong in the installation and check recursively from there for permissions? Or even some sort of provision in the configuration file for files/folders to explicitly ignore during installation, and put the onus on the end user to fill them in?

But alright, if you really must scan every file that might be in there, is there some way to at least cause the permissions failure to be a non-fatal error, so the update can continue in peace without having to manually bypass that functionality? Some sort of override in the configuration file similar to disabling auto-update? Plastered with giant warnings that it's a horrifying idea and that sad, lonely kittens will cry in sorrowful harmony if it's enabled, but still there as an option?

Thank again you for your time.

[shaunw]

The installer only checks the integrity of a specific list of files, but during install/upgrade/maintenance procedures TimeTrex may need to access, delete, move, overwrite or copy other files not on that list, for example cache, storage or log files.

The primary use case for this is the maintenance jobs, its a common mistake by users to setup the maintenance jobs to run as a different user than the web server, causing a permission conflict that is sometimes difficult to detect, as the web server may write a file to the disk owned by it, then the maintenance jobs try to read/write/delete that same file as a different user and they can't, this is especially bad for caching functionality, which can cause corrupted data and unexpected behavior of the application.

So permission issues definitely require a "fatal error" to help prevent the above from occurring.

[jcdubois]

Alright, and that certainly makes a certain amount of sense. Yet, all three of those - cache, storage, and logs - are files that have something to do with TimeTrex. Additionally, we're providing explicit paths to those three folders in the configuration file, so you should know exactly where they are. Again, I'm having a lot of trouble reconciling what you're saying with what I see happening. I can't help but come back to the fact that you're demanding files that have absolutely no relation to TT in any way, shape or form beyond happening to share a web root folder be writable.

Let me change the question a little - when I was adding the bypass, I noticed the following -

Code: Select all

if ( PRODUCTION == FALSE OR DEPLOYMENT_ON_DEMAND == TRUE ) {
       return 0; //Skip permission checks.
   }

It looks to me as there's already a bypass in place - What would be the ramifications of setting DEPLOYMENT_ON_DEMAND to true, and is there a way to do so in the config file?

Thanks again, I promise I'll go away after this.

[shaunw]

DEPLOYMENT_ON_DEMAND is used for cloud hosted installations of TimeTrex, so it changes a lot of the functionality as it expects certain things to be in place and therefore won't function with the On-Site Community Edition.