Need Parameters for the OTRS Appliance

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]

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]

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?

And fixes your original bug?

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

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.

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.

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

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.

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.

Thoughts?

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 \
    /usr/share/otrs

Update:

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).