raymccoy's picture

Just intstalled otrs with the turnkey-otrs-11.0rc-lucid-x86.iso . All
went perfect but if i trying to use the paketmanager

is got an error:
ERROR: Need write permission in OTRS home
Try: $OTRS_HOME/bin/SetPermissions.pl !!!

For help, please send mail to the webmaster (webmaster@localhost),
giving this error message and the time and date of the error.

So maybe you only need the distribute the right parameters for the users
you downloaded the turnkey-otrs-11.0rc-lucid-x86.iso and want to test.

root@otrs otrs/bin# ./SetPermissions.pl
bin/SetPermissions.pl <> - set OTRS file permissions
Copyright (C) 2001-2009 OTRS AG, http://otrs.org/
Usage: SetPermissions.pl

Have reported this as a bug but maybe some one can help with quick instruction to use the

root@otrs otrs/bin# ./SetPermissions.pl the right way.

Jeremy Davis's picture

See the OTRS Wiki (right at the end of the installation section) for full details, but here's the line to try:

cd /opt/otrs
bin/SetPermissions.pl --otrs-user=otrs --otrs-group=otrs --web-user=www-data --web-group=www-data /opt/otrs

cd /usr/share/otrs
bin/SetPermissions.pl --otrs-user=otrs --otrs-group=otrs --web-user=www-data --web-group=www-data /usr/share/otrs

Please post back if that line fixes it. If so then it is indeed a bug (and probably worth posting a link back here on the bug report too), if not then we'll need to investigate a little more.

[edit - adjusted commands above, see post below]

raymccoy's picture

in the turnkey-otrs-11.0rc-lucid-x86 appliance the otrs is installed into

/usr/share/otrs and no otrs user is created.

so the command has to be

cd /usr/share/otrs

bin/SetPermissions.pl --otrs-user=root --otrs-group=root --web-user=www-data --web-group=www-data /usr/share/otrs

This command does it but i don't know if this is the right way?

Jeremy Davis's picture

Well spotted on the path variation. www-data is the standard Apache/webserver user so most web apps run under that so granting www-data permissions is fine. I'm not sure about using root instead of otrs though. Did you try it without the otrs user at all (ie just the www-data bits)?

Normally root has system wide permissions anyway so I don't think that's too much of an issue. Only thing is if there are processes running under root. That wouldn't be good! Ie it shouldn't need root permissions and if it does, that could mean security problems.

Regardless it is obviously a bug in this appliance, so well spotted. I guess we'll need to let the devs to decide whether what the correct way to fix it is. Hopefully they'll let us know here.

PS I'll update the path in my command in the post above - I'll leave the otrs user there until we work it out for sure.

[edited for a 3rd time because I finally read the post I was responding to - sorry about that]

raymccoy's picture

Okay the command must be:

cd /usr/share/otrs

bin/SetPermissions.pl --otrs-user=otrs --otrs-group=otrs --web-user=www-data --web-group=www-data /usr/share/otrs

So the otrs user is still called otrs.

Jeremy Davis's picture

And fixes your original bug?

PS sorry about not reading your last post properly before replying and having to edit so many times!

raymccoy's picture

Yes it fixes the original told bug!

So i if one will download the turnkey-otrs-11.0rc-lucid-x86.iso and did an install. He can login into the otrs system with the credetionals told by the doku of the turnkey otrs appliance. All seems to be fine but if the otrs-admin will choose to open the AdminPackageManager anyone will get the errorERROR: Need write permission in OTRS home until he will fix this with the following commands:

cd /usr/share/otrs

bin/SetPermissions.pl --otrs-user=otrs --otrs-group=otrs --web-user=www-data --web-group=www-data /usr/share/otrs

Jeremy Davis's picture

I love it when bugs get squashed! Now we just have to get Alon to fix it for the release! :)

I have also put a comment on the bug report about the fix, and a link back to this thread.

Alon Swartz's picture

Firstly, great work folks!

This bug puzzled me as it's not like upstream to make mistakes like this. After going over the packaging source code, I can only say that this is not a bug that can be reported upstream, as the reply we'll get is: it's a security feature.

What's happening is:

  • the packaging post installation script is executing:
$OTRSHOME/bin/SetPermissions.sh $OTRSHOME otrs www-data www-data www-data
  • SetPermissions.sh in turn is executing SetPermissions.pl with the appropriate arguments, but the kicker is that it includes the --secure flag.

The --secure flag is setting restrictive permissions on OTRSHOME (i.e. /usr/share/otrs and /var/lib/otrs), with the side effect of not allowing the web-user write permissions, which is required when using the OTRS package manager. From a security stand point this is good practice, but from a user perspective it seems like a bug.

So, I'm a little conflicted as to whether to disable the security settings or not. Our options:

  • Leave the appliance as is, and document how to relax permissions on the appliance page.
  • Make the change, and document how to secure permissions on the appliance page.


BTW, there is no otrs group defined, so the correct command would be:

/usr/share/otrs/bin/SetPermissions.pl \
    --otrs-user=otrs --otrs-group=www-data \
    --web-user=www-data --web-group=www-data \



I had a quick chat Liraz and we came to the conclusion that it's better to optimize for convenience/usability. Once the user has setup and configure OTRS to his liking, he can then lockdown the permissions to increase security (we'll document how to do that on the appliance page).

Liraz Siri's picture

As we agreed, the first order of business once you've installed an appliance is to customize it and get it to work to your liking. Disabling this security features means it's easier to do that. It makes sense to turn this off by default because TurnKey's job is to provide the ideal starting point, not the ideal end point.

After that if you are putting the machine into production on an untrusted network, might want to consider turning it back on to tighten the screws. Only people who care about the extra security will read the documentation and turn it back on, and since you'll have to do it manually that will make sure you know how to turn it back off again if you need to do more customization.

There's an important difference between opening a vulnerability and disabling redundant security features.

The security implications of turning this security feature off by default aren't severe in this case. It just means that if there is a vulnerability in OTRS the attackers get through, they can modify the running OTRS installation without needing another privilege escalation exploit.

Add new comment