Hestiacp: Apache access and error logs not viewable by website user

[johnnyq]

In a few words, please describe the issue that you're experiencing:

when a user logs in via ssh and attempts to view Apache access logs and error log with cat they get a permission denied.

What steps did you take when the issue occured?

1. login in via ssh
2. cd /home/USER/web/WEBSITE/logs
3. cat SITE.log or cat SITE.error

Expected behavior:

logs should be viewable for that site that belongs to the logged in user

Operating system distribution and release:

Ubuntu 18.04.3 LTS

Which version of Hestia Control Panel is currently installed?

1.0.6

Which branch are you using?

release

When did this issue occur? After a clean installation, or after an upgrade?

Just noticed this

Note: If you have upgraded from an older release on an existing server, please let us know which version was previously installed if at all possible.

Which of the following web server configurations are you using?

• Apache + Nginx (default)

Which of the following server roles are installed on your server?

• DNS
• Mail (Dovecot + Exim)
• MySQL (MariaDB)

[cmstew]

Hi @johnnyq

I dug a little into this and I'm pretty sure it has to do with the way logrotate is configured. Basically, the logs start out with the correct permissions when creating a domain and then when logrotate runs it changes the group to adm.

I think this is the offending line in the logrotate config file:

create 640 nginx adm

I haven't figured out a fix yet otherwise I'd submit a pull request, but I figured I'd point you in the right direction in case you felt like digging a little in the meantime. Here is a link to the file:

https://github.com/hestiacp/hestiacp/blob/master/install/deb/logrotate/nginx

[ScIT-Raphael]

@cmstew Thanks for the good debug you did there! I can confirm, that the issue happens due to logrotate - this affects apache2 and nginx log files.

One possible solution would be to create a "fix permission script", that will be triggered after every run of logrotate which will set the right owner (something like v-change-web-log-permission). Does anyone have another idea, how we could fix this?

[cmstew]

@ScIT-Raphael I think I just found a better fix. I just read the logrotate manual for the create option and it looks like you can inherit the original ownership attributes if you omit changing them with the command.

create mode owner group

Any of the log file attributes may be omitted, in which case those attributes for the new file will use the same values as the original log file for the omitted attributes.
https://linux.die.net/man/8/logrotate

So if we changed the line to be this instead, the problem should be solved:

create 640

I'll just run a few tests and then report back.

[johnnyq]

Oh that is Super!! Nice find!! thanks @cmstew and @ScIT-Raphael