Regular "Permission denied" in cronjobs since update to 3.2

[fthommen]

Hi,

since updating to 3.2 (RPM install on CentOS 5) I regularly get permission error messages from the various cronjobs (otrs.PostMasterMailbox.pl, otrs.DeleteCache.pl, otrs.LoaderCache.pl) (see also the german threads "otrs.PostMasterMailbox.pl: Permission Denied fuer 'mkdir'" and ""Permission denied" bei Cronjobs seit Update auf 3.2"). Examples:

• Message: Can't remove file /opt/otrs/var/tmp/CacheFileStorable/CacheInternalLoader/a/5/a5a7a46de71ce8a7f3f0961aecf5c8ba: Permission denied
• Message: Can't write '/opt/otrs/var/tmp/CacheFileStorable/CacheInternalTicket/8/f/8fd2c543e3d23358aec0983fbda050cf': Permission denied
• mkdir /opt/otrs/var/tmp/CacheFileStorable/DynamicFieldValue/b/8: Permission denied at /opt/otrs/Kernel/System/Cache/FileStorable.pm line 81

The directory in question is of course not always the same. Sometimes the script finally succeeds or - in the case of otrs.PostMasterMailbox.pl - I fetch the mail manually from the administration panel. In fact ther permissions of some directories seem to be wrong. Example:

Code: Select all

# ls -al /opt/otrs/var/tmp/CacheFileStorable/DynamicFieldValue
total 64
drwxrwsr-x 16 otrs   apache 4096 Sep 17 19:13 .
drwxrwsr-x 26 otrs   apache 4096 Sep 16 10:48 ..
drwxrwsr-x  4 otrs   apache 4096 Sep 16 12:30 0
drwxrwsr-x  6 otrs   apache 4096 Sep 17 14:40 1
drwxr-sr-x  3 apache apache 4096 Sep 10 19:47 2
drwxrwsr-x  4 otrs   apache 4096 Sep 16 15:10 3
drwxr-sr-x  3 apache apache 4096 Sep 17 19:13 4
drwxr-sr-x  4 apache apache 4096 Sep 17 19:13 5
drwxrwsr-x  4 otrs   apache 4096 Sep 17 19:13 6
drwxr-sr-x  3 apache apache 4096 Sep  9 18:53 8
drwxrwsr-x  5 otrs   apache 4096 Sep 17 14:50 9
drwxrwsr-x  6 otrs   apache 4096 Sep 17 19:13 a
drwxr-sr-x  4 apache apache 4096 Sep 17 19:13 b
drwxrwsr-x  4 otrs   apache 4096 Sep 17 19:13 c
drwxrwsr-x  5 otrs   apache 4096 Sep 17 14:50 d
drwxrwsr-x  5 otrs   apache 4096 Sep 17 19:13 e
# ls -al /opt/otrs/var/tmp/CacheFileStorable/DynamicFieldValue/b
total 16
drwxr-sr-x  4 apache apache 4096 Sep 17 19:13 .
drwxrwsr-x 16 otrs   apache 4096 Sep 17 19:13 ..
drwxr-sr-x  2 apache apache 4096 Sep 10 19:03 0
drwxr-sr-x  2 apache apache 4096 Sep 17 19:13 8
# 

The involved accounts are 'otrs' and 'apache':

Code: Select all

# id -a otrs
uid=500(otrs) gid=48(apache) groups=48(apache)
# id -a apache
uid=48(apache) gid=48(apache) groups=48(apache), [...und viele andere nicht relevante...]
# 

Code: Select all

/opt/otrs/bin/otrs.SetPermissions.pl --otrs-user=otrs --web-user=apache --otrs-group=apache --web-group=apache /opt/otrs

has been run, but this solved the problem only for a while.

The problem seems to be, that directories created by 'apache' (via Web frontend) are missing write permission for the group, while directories created by 'otrs' (through cronjobs) have correct permissions. Any idea how to solve this problem? It's very annoying and I didn't have this with OTRS 3.1

frank

[crythias]

you may need to make sure the apache job runs as otrs

[fthommen]

you may need to make sure the apache job runs as otrs

Thanks. Yes, that would probably solve it, but such a webserver setup not possible in our context. It would probably break (all) other websites and create additional collateral problems.

Questions that come to my mind are

1. How is OTRS supposed to work (after all there is an option "--web-user=" to otrs.SetPermissions.pl so I assume OTRS should work fine with a separate webserver user)?
2. How comes this problem only appeared after the update from 3.1 to 3.2?
3. Isn't this maybe a bug, that web-initiated jobs don't create files with right group permissions?

Cheers
frank

[crythias]

centos is also problematic (disable selinux).

OTRS will create temp folders as the apache user. This is not unique to otrs... "apache" is creating the temp.
otrs runs cron as otrs user.

Even if you've setPermissions, you're only setting permissions on folders that already exist. New folders are created under the user that creates them... whatever apache runs under.
add otrs as a member of apache group (usermod?) and it appears you'd be less likely to have issues.
Edit: no, apparently group is not adding write access, so there's that.

[fthommen]

centos is also problematic (disable selinux).

In which respect is CentOS problematic? SELinux is already disabled

OTRS will create temp folders as the apache user. This is not unique to otrs... "apache" is creating the temp.
otrs runs cron as otrs user.

That's clear, but this never created problems so far. I was happily running OTRS 3.1 for a long time w/o these errors.

[...]. add otrs as a member of apache group (usermod?) and it appears you'd be less likely to have issues.

As you can see from the original post, this is already the case.

Edit: no, apparently group is not adding write access, so there's that.

What does "so there's that" mean? Does it mean "this cannot be changed" or "this is the problem"? If it means the latter, then this corresponds exactly to my initial analysis. Still the question remains: Why? Where's the problem?

The OTRS installation instructions don't mention, that the webserver must/should be run as 'otrs' user. So imho this can't be the problem.