You are here
Just intstalled otrs with the turnkey-otrs-11.0rc-lucid-x86.iso . All
went perfect but if i trying to use the paketmanager
https://192.168.178.145/otrs/index.pl?Action=AdminPackageManager
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 <1.10.2.1> - set OTRS file permissions
Copyright (C) 2001-2009 OTRS AG, http://otrs.org/
Usage: SetPermissions.pl
[--otrs-user=<OTRS_USER>]
[--web-user=<WEBSERVER_USER>]
[--otrs-group=<OTRS_GROUP>]
[--web-group=<WEB_GROUP>]
[--admin-user=<ADMIN_USER>]
[--admin-group=<ADMIN_GROUP>]
[--admin-group-writable]
[--secure]
[--not-root]
<OTRS_HOME>
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.
The OTRS Wiki suggests this:
See the OTRS Wiki (right at the end of the installation section) for full details, but here's the line to try:
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]
in the
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?
Excellent, good work.
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]
Okay the command must
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.
Ok, so that works for you?
And fixes your original bug?
PS sorry about not reading your last post properly before replying and having to edit so many times!
Yes it fixes the original
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
Awesome!
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.
It's not a bug, it's a (security) feature
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 --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:
Thoughts?
BTW, there is no otrs group defined, so the correct command would be:
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).
Defaults should favor convenience over premature lock-down
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