[Koha-bugs] [Bug 1993] Task Scheduler Needs Re-write

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1993

MJ Ray (software.coop) <mjr at software.coop> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|In Discussion               |Signed Off
                 CC|                            |mjr at software.coop

--- Comment #8 from MJ Ray (software.coop) <mjr at software.coop> ---
(In reply to comment #6)
> This patch doesn't seem to address the security concerns raised by Atz in
> the last imported comment... could someone speak to this before it is
> processed through QA?  What precautions are taken?  What vulnerabilities are
> possible?

Surely that shouldn't block the improvement patch?

The last comment from Atz was "Please note that there are big security issues
for using "at" (or in this case "atq") in a multiple-client hosting
environment, since each Koha will be running as the same "apache" user.  There
is no differentiation on what jobs are visible: everybody will see everything."

That has never been best practice and I'd be surprised and disappointed if
liblime did it.

The current packages for debian use apache-mpm-itk to constrain each individual
vhost to a particular system user, so the above vulnerability doesn't occur in
that way. Other installers could use the same MPM, or they could use other
apache modules like mod_ruid to achieve a similar isolation.

If all virtualhosts were running as one user, the vulnerability would have
meant that libraries could mess with each others' jobs - deleting, amending,
adding jobs for other libraries - but they've probably also got other security
vulnerabilities that would arise from the lack of isolation.  I suspect most
people who install it themselves and don't follow best practice are only
hosting one library, in which case the vulnerability wouldn't occur because
there are simply no other libraries to mess with.

That's probably a QA or RM decision that boils down to: do we design Koha to
work well under best practice, or not implement a feature because someone could
cause a security flaw with it?

But I'm not sure the security concern applies if installed in as suggested by
any INSTALL* files, does it?  I think the only installation method that
addresses multiple Koha hostings are the packages for debian and they seem
safe.

The later comment about using cron is sound, but I think C4::Scheduler uses
cron when appropriate now anyway.  It may be better to implement C4::Scheduler
with a cron job that uses koha-foreach or multiple user crontabs to review the
scheduled tasks every 10 minutes or something, but the current system-level
method doesn't seem awful.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are watching all bug changes.