What Files, What Permissions

[herb200mph]

In the installation instructions, there is mention of a list of files that will display that will need their permission altered to complete an install.

We are not seeing those files, see another post about Installation Failure.

Can someone post the list of the files that need to be changed and what their permissions should be.

Thank you.

[andrewatfornax]

https://documentation.revive-adserver.com/display/DOCS/Directory+Permissions

[scott001]

Right now I have those directories all set to 644, but am getting this error:

Error: File permission errors detected.
These may impact the accurate delivery of your ads,
See the debug.log file for the list of unwritable files

Can you tell me the exact permissions they need? I thought 644 does allow the server to read and write, but apparently not. Do I need to allow the world to read and write with 777?

Thank you in advance.

[andrewatfornax]

https://documentation.revive-adserver.com/display/DOCS/Directory+Permissions

[scott001]

I correctly applied those permissions yesterday, 777 so those directories and their sub-directories, yet when I logged in today I got this error again:

Error: File permission errors detected.
These may impact the accurate delivery of your ads,
See the debug.log file for the list of unwritable files

I double checked, and the permissions are correct. Also, I checked the debug.log, which I emptied yesterday, and nothing is there.

Any ideas?

[andrewatfornax]

Check that all the files in the directories & sub-directories are also writable?

[scott001]

It doesn't seem safe to put 777 permissions on .htaccess and php files...but I will check.

This can't be right, you would have me put 777 on my conf file??? It is in /var...

[scott001]

I certainly hope you can be more clear, as I keep seeing this error and can't believe that you'd have me 777 files like conf.

[scott001]

Ok, so no reply...again, are you saying that I need to chmod my configuration file to 777? Would this not open it up, including my passwords, to the world?

[Maro]

644 is ok for running server, but for installation and upgrading some folders should be set to 777, like mentioned in the documentation. The conf file can be 444, but for changes it must be writable to the owner.

Make sure the folders have the correct owner and group, like www-data for the owner. I'm using plesk, the owner is a user i named when creating the website subscription.

[andrewatfornax]

On 6/2/2018 at 3:43 AM, scott001 said:

Ok, so no reply...again, are you saying that I need to chmod my configuration file to 777? Would this not open it up, including my passwords, to the world?

Patience my friend. 

No, the conf files don't have to have 777 permissions. The various conf files only need to be writable by the web server user, if you want to update the configuration via the web UI. If you don't want to do that, then you don't need to have any write permissions on the config files - so long as the web server can read them, then you are good.

However, under Revive Adserver's var directory, there are a number of subdirectories, and both var and all of the subdirectories, and their subdirectories, etc. are where Revive stores and caches all kinds of data.

All of these directories and their files must be able to be read and written by the web server user.

777 is not needed, but you will need an approach that allows the correct level of access - for many users with limited Unix experience, 777 is therefore a convenient approach.

[scott001]

I know I seem like I am being a pain about this, but there are issues with what you say here:

https://documentation.revive-adserver.com/display/DOCS/Directory+Permissions#DirectoryPermissions-WritePermissions

For example, within my var/cache I see a cached version of my conf file, complete with passwords. If I 777 all files under /var 777, then it will be open to the world.

I only ask that you be precise, so that my server, and perhaps others, don't get hacked. Due to this situation, I am still unclear which files need 777.

[scott001]

For example in /var/cache I seethis file which contains my site login/password:

www.mydomin.com_admin_container.php

Your instructions are telling me to chmod this 777, right?

[scott001]

Here is what you currently say:

The web server requires the ability to write to the following Revive Adserver directories and all files/directories under these locations:

var var/cache var/plugins var/templates_compiled plugins www/admin/plugins www/images

 

And here is what I believe it should say (note that I removed the var and plugins listings, because I don't think you mean those. I think you mean only the ones listed under those):

The web server requires the ability to write to the following Revive Adserver directories and MOST files/directories under these locations (FOR APACHE THIS IS 777):

var/cache (EXCEPT THE PHP FILES IN THERE, WHICH SHOULD BE 644) var/plugins var/templates_compiled www/admin/plugins www/images

[andrewatfornax]

On 6/5/2018 at 3:50 AM, scott001 said:

If I 777 all files under /var 777, then it will be open to the world.

Correct - which is why I have not said that you should use chmod 777.

I think my previous reply was quite correct - read/write access is required (for full Revive Adserver functionality - you can prevent write access to your configuration files if you want to lock down changes to the files via the admin UI, but that's a separate issue), and chmod 777 is a convenient way for users to do that - but it not what I recommend, and it's not what the documentation says.

On 6/5/2018 at 3:50 AM, scott001 said:

I only ask that you be precise, so that my server, and perhaps others, don't get hacked. Due to this situation, I am still unclear which files need 777.

I think I have been precise - what is required is read/write access from the web server. 

There are several ways to achieve that, and chmod 777 is the worst way, which is why we don't say that in the docs, and say (more precisely) what read/write permissions are needed.

On 6/5/2018 at 4:10 AM, scott001 said:

For example in /var/cache I seethis file which contains my site login/password:

www.mydomin.com_admin_container.php

Your instructions are telling me to chmod this 777, right?

No, I don't believe that at any point have I said in the forums, or in the documentation, that you should chmod 777 anything. 

If you do see that written somewhere, especially in the documentation, though, please let me know, and I will happily fix it.

On 6/5/2018 at 4:29 AM, scott001 said:

And here is what I believe it should say (note that I removed the var and plugins listings, because I don't think you mean those. I think you mean only the ones listed under those?

The web server requires the ability to write to the following Revive Adserver directories and MOST files/directories under these locations (FOR APACHE THIS IS 777):

var/cache (EXCEPT THE PHP FILES IN THERE, WHICH SHOULD BE 644) var/plugins var/templates_compiled www/admin/plugins www/images

I respectfully disagree with you here. I do not believe that our documentation should advise anyone to use chmod 777 for anything. It is an overly permissive approach that I do not recommend.

Sometimes, for some users, it's the right way to get the job done - but there are better approaches. 

However, as always, what is important to some users is not relevant to others, so, we leave it to the user to decide the best approach of assigning the read/write permissions required for their individual circumstances. (For example, if you have a physically secure server, that has no general user access to it, then chmod 777 may well be a perfectly acceptable approach for you. But I'm not going to recommend chmod 777 in our docs.)

[jpt]

https://www.revive-adserver.com/support/upgrading/

This page in the Revive Adserver docs recommends chmod 777. Is that page incorrect? What should I be doing instead when I upgrade my Revive Adserver instance?

[scott001]

It's your software, why not just give the exact permissions we need to set with a publicly facing site??? I don't write your software, but as a user I need to know this. Your software is throwing errors--based on what? The site you send me to to fix those errors doesn't have the required information for me to fix those errors, yet you keep sending people there.

PS - I would not set this file /var/cache/www.mydomin.com_admin_container.php to anything other than 644 or higher, perhaps even 444 if that would work.

So why not just give your users the most conservative setting that will prevent the software from throwing the errors? That is all I am saying here. Why leave us to guess from dozens of possible permissions?

Edited June 6, 2018 by scott001

[scott001]

Also, I discovered more files that contain my site's login info, which should probably also have at least 644 permissions. 

So we know about the config file which should probably be 444:

var/www.mysite.com.conf.php

But also in /var/cache are the following which contain your site's login info/passwords, which probably should be at least 644, if not 444:

var/cache/localhost_admin_container.php
var/cache/www.mysite.com_admin_container.php.meta
var/cache/localhost_admin_container.php.meta

Don't forget this one mentioned earlier:

var/cache/www.mysite.com_admin_container.php

[andrewatfornax]

10 hours ago, jpt said:

https://www.revive-adserver.com/support/upgrading/

This page in the Revive Adserver docs recommends chmod 777. Is that page incorrect? What should I be doing instead when I upgrade my Revive Adserver instance?

Ah, thank you. I did not know about that one. 

I will look into getting this changed.

What you should be doing is setting appropriate read/write permissions for your system.

6 hours ago, scott001 said:

It's your software, why not just give the exact permissions we need to set with a publicly facing site???

Yes, Revive Adserver is our software - but it's not a complete solution. It needs a webserver, and an operating system underneath it as well, and those things vary greatly, and you can set things up there in a huge number of ways.

It's like getting a new car radio, and the manual says before you install the new radio, make sure your car is switched off, and the handbrake is on, but then complaining that the car radio manual doesn't give you exact details on how to switch off your car and apply the handbrake for your exact car. Would you really expect the manual to document every single possible car model in the world, and describe how to do those things? No, you'd expect that the general information is sufficient, because if you're not sure how to do those things with your car, then it's reasonable to expect you to go away and look in the car's manual on how to do that.

We expect the same thing - we tell you that you need to set read/write permissions on certain files and directories, and we expect you to look at your webserver/operating system manual, and do so in an appropriate way for your needs.

7 hours ago, scott001 said:

PS - I would not set this file /var/cache/www.mydomin.com_admin_container.php to anything other than 644 or higher, perhaps even 444 if that would work.

And that's kind of the point - what you would do may or may not be suitable for everyone.

7 hours ago, scott001 said:

So why not just give your users the most conservative setting that will prevent the software from throwing the errors? That is all I am saying here. Why leave us to guess from dozens of possible permissions?

Well, we do, in a way - we say what files and directories need to have read/write permissions by the webserver that's delivering the site. That's the minimum required, and if you do this in a way that's appropriate for your setup, then you will be good.

[scott001]

Sorry to bring this up again, but I upgraded yesterday and ran into more permission issues. So the command that your software said I need to run before upgrading was:

• chmod -R a+w /public_html/revive/var

This puts permission for everything in that directory at 666. The problem is that there are a few files in /var/cache that contain my database password info, like www.mysite.com_admin_container.php and localhost_admin_container.php. Do you agree that these probably should not be at 666?

Changing these to 644 or 444 seems to trigger the warnings.

 

[scott001]

Just FYI, here is how I've been doing this, and it stopped the errors, and I believe is a secure way to run for most apache users:

chmod -R a+w /revive/var
chmod -R 644 /revive/var/cache/*.php
chmod -R 644 /revive/var/cache/*.php.meta
chmod -R 444 /revive/var/www.my-domain.com.conf.php
chmod -R a+w /revive/var/plugins/
chmod -R a+w /revive/var/templates_compiled/
chmod -R a+w /revive/www/images/
chmod -R a+w /revive/www/admin/plugins/

PS - These should be run in order from top to bottom.

Edited August 11, 2018 by scott001

[scott001]

Sorry to flog a dead horse, but the permissions above still create issues. So these make all errors go away, and seem to be the default setting for most people (just in case, a+w = 666):

chmod -R a+w /revive/var
chmod -R 444 /revive/var/www.my-domain.com.conf.php
chmod -R a+w /revive/var/plugins/
chmod -R a+w /revive/var/templates_compiled/
chmod -R a+w /revive/www/images/
chmod -R a+w /revive/www/admin/plugins/

However, when I protect the files below, some of which contain passwords to my database, the software throws the permission warnings.

chmod -R 644 /revive/var/cache/*.php
chmod -R 644 /revive/var/cache/*.php.meta

What is your view on these files? Should they not be protected better, given that they contain sensitive info?

Edited September 26, 2018 by scott001

[andrewatfornax]

Hi @scott001,

Sure, you are absolutely welcome to put more restrictive permissions in place - just ensure that the user that Revive Adserver executes as (see your PHP/webserver documentation) can read/write the directories and files, and you will be golden!

[AngryWarrior]

Hi @andrewatfornax

I'm just about to upgrade my revive server and in the process i started to go over the file perms and the documentation about it.

I must admit after reading the docs and this thread I'm really confused about it.

The page https://www.revive-adserver.com/support/upgrading/ tell you to use 777, but here in the thread it is NOT advised at all.(The documentation should really be updated to the correct file permission recommendations and not 777, and I too really dislike to use 777 too because it is dangerous for obvious reasons.). You also say here that you would not recommend anyone to use that permission etc.

So I am kindly asking for the benefit of everyone and anyone that uses Revive Adserver if this could be settled once and for all?

What is exactly the absolutely correct permissions for files and directories as they clearly should not run on 777 for a vanilla Revive server. Could you please clearly cut this out in the sand what permissions in that should be used for a vanilla/standard installation?

For folders permission number?

var
var/cache
var/plugins
var/templates_compiled
plugins
www/admin/plugins
www/images

and for files permission number?

It would be great to have this cleared once and for all.

 

All this contradicting information makes no good for anyone. Not for the Revive community and neither for Revive Adserver as product itself.

Thanks a lot in advance.

Kind regards
AngryWarrior

 

Edited July 13, 2019 by AngryWarrior

[andrewatfornax]

Most correct answer, as far as I am concerned:

• The user that your web service runs as needs permissions to read all directories (and all of the files and sub-directories) of the entire Revive Adserver installation; and
• The user that your web service runs as needs permission to write to all of the specifically listed directories (and all of the files and sub-directories underneath them).

There you go - that's my view on the most correct answer - and you will notice I not said anything about how you should achieve that. This is because I can think of a number of different ways to do this, depending on your operating system and/or preferences about how you manage security. 

So, while it's the most correct answer, it's of absolutely no help to many (most?) of our users, because they don't have the technical experience needed to set this up.

That's why we suggest something rather permissive in our documentation - we don't have time to support every single new user installing the software to get a custom setup that's just right for their security needs. We assume that if you're the kind of user who is concerned about getting the security requirements just right, then you have the capability to tweak the permissions to what your needs are.

HTH!