Bug#475737: remove otrs2 from lenny?

2008-12-05 Thread Marc 'HE' Brockschmidt
Torsten Werner [EMAIL PROTECTED] writes:
 On Sat, Nov 22, 2008 at 9:48 AM, Thomas Viehmann [EMAIL PROTECTED] wrote:
 given that there seems to be limited interest in fixing the #475737 (3
 weeks since reopen without further comments), how about removing otrs2
 from lenny?

 I had sent the following reply to the list (but not to the bug) weeks
 ago but I did not get an answer so far:

I tried to bring a bit of order into this mess. In #475737, two issues
were covered:
 (i) Files in /usr are written.
(ii) The web frontend (aka www-data) is able to write random perl code
 into files that are later executed by the otrs2 user

So, we can fix (i) easily: Just push the config file to somewhere in
/var or /etc, fix the code or symlink it in from /usr, make it writable
by www-data and we are done. Moving it to /etc seems a bit evil, as this
data isn't meant to be changed manually, so /var seems like the better
option.

(ii) is a more complex issue, and I would consider this as something
that could get a lenny-ignore tag. The main problem, communication
of configuration changes between the web frontend and the rest of the
OTRS suite, enforces some way of passing information. Using
turing-complete perl code for that isn't the best way. 
Luckily, OTRS already uses XML for its configuration in quite a few
places, and it might be a reasonable idea to use exactly that for the
web frontend. The general idea would then be to write out XML
configuration files as www-data, which are then parsed by
Kernel::System::Config. This would also get rid of the horrible
_XML2Perl function currently used.

This is a big, long-term change that should be discussed with
upstream (and I'm willing to propose this, and write code for it). What
do you think?

Marc
-- 
BOFH #167:
excessive collisions  not enough packet ambulances


pgpwJLmaNfyst.pgp
Description: PGP signature


Bug#475737: remove otrs2 from lenny?

2008-11-22 Thread Thomas Viehmann
Hi,

given that there seems to be limited interest in fixing the #475737 (3
weeks since reopen without further comments), how about removing otrs2
from lenny?

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#475737: remove otrs2 from lenny?

2008-11-22 Thread Luk Claes
Thomas Viehmann wrote:
 Hi,
 
 given that there seems to be limited interest in fixing the #475737 (3
 weeks since reopen without further comments), how about removing otrs2
 from lenny?

I'll have a look at fixing it.

Cheers

Luk



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#475737: remove otrs2 from lenny?

2008-11-22 Thread Torsten Werner
Hi Thomas,

On Sat, Nov 22, 2008 at 9:48 AM, Thomas Viehmann [EMAIL PROTECTED] wrote:
 given that there seems to be limited interest in fixing the #475737 (3
 weeks since reopen without further comments), how about removing otrs2
 from lenny?

I had sent the following reply to the list (but not to the bug) weeks
ago but I did not get an answer so far:

I agree that it is a FHS violation that will be fixed in unstable and
that we have lived with the problem in sarge and etch but I do not
agree that it is a security problem. That is why I ask for an
exception for lenny.  Let me quote from the bug report:

... every web application has read access to /etc/otrs/database.pm
which means it can create havoc in the database, install stored
procedures and so on. Every other webapp with a database has the same
problem - not only otrs. It is the duty of the local admin to make
sure that the installation is safe. I do not understand what is so
special about otrs...

It is not hard to modify foreign databases when it comes to webapps
that are executed by the same httpd user and BTW stored procedures are
executed in the context of the postgres user.

I am sorry that the FHS issue cannot be fixed easily but the bug
report came very late before the freeze.


Torsten



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]