Bug 14774

Summary:	Task Scheduler not working on Ubuntu/Apache2.4
Product:	Koha	Reporter:	Liz Rea <liz>
Component:	Task Scheduler	Assignee:	Tomás Cohen Arazi (tcohen) <tomascohen>
Status:	CLOSED WORKSFORME	QA Contact:	Testopia <testopia>
Severity:	normal
Priority:	P5 - low	CC:	craig, fooquency, robin, tomascohen
Version:	Main
Hardware:	All
OS:	All
Change sponsored?:	---	Patch complexity:	---
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:

Description Liz Rea 2015-09-03 02:08:03 UTC

The task scheduler uses At to schedule reports to be run later. It's doing something weird in Ubuntu 14, Apache 2.4.

Scheduling a task on Debian/Apache 2.2 results in the job being added, and it showing up in the web page. This doesn't happen on Ubuntu/Apache 2.4, it returns a "Failed to add job."

It looks like Koha is asking atq for the list of current jobs (through Schedule::At) and it's not getting a list back when run on Ubuntu/2.4. This all works just fine in Debian/2.2.

in /var/spool/cron/atjobs we can see where jobs are added:

Failing job "Failed to add job", Ubuntu, Apache 2.4:
---------- 1 daemon daemon 2.9K Sep  2 15:19 a0004a016e87ae

Successful job displays in the web page, Debian, Apache 2.2
-rwx------ 1 library-koha daemon 2.8K Sep  2 16:15 a00014016f1f52

When we ask for the euid/gid of the user when trying to add these failed jobs, it seems like it should be OK:

uid: 1005, euid: 1005
  
Which corresponds to the uid given in /etc/passwd:
library-koha:x:1005:1005

As far as I can tell, those daemon:daemon no permissions jobs aren't actually run - how could they, they have no executable permissions.

Pretty sure this bug isn't in Koha proper (the scheduler actually works just fine in Debian/2.2), but some interaction or security thing in Ubuntu/Apache 2.4. It might be nice to figure out why it happens, so we can end run the problem (or decide to scrap the At reliant scheduler, which is probably a "should do" anyway).

Comment 1 Craig Miskell 2015-10-08 02:11:39 UTC

It appears based on some debugging that when running under apache-mpm-itk, setuid binaries like 'at' don't have quite enough permissions to do what they need. While it does end up running as daemon.daemon, and can write to files in /var/spool/cron/atjobs/, it fails at the fchown step with EPERM.  From the docs for fchown, that means "The effective UID does not match the owner of the file, and the process is not privileged (Linux: it does not have the CAP_FOWNER capability))". 

Without going deeper, I expect this is a result of mpm-itk dropping capabilities or privileges to get down to the run-time user, and not being able to elevate back up as a result. This would affect any other setuid programs too.

Converting to some sort of app-layer (starman? plack?) may solve it, where apache runs as normal, and the application runs out of app processes that run as the correct user from the start, and which can therefore setuid back up.

Comment 2 Liz Rea 2015-10-08 02:53:57 UTC

In additional, unexpected news: Debian Jessie seems to be unaffected, and honestly I expected it would be.

Comment 3 fooquency 2016-12-05 18:13:28 UTC

On Ubuntu 14.04, I found that installing koha, which installs mpm-itk broke Exim4 mail sending.

I found, as per the references below, that adding the following directive to the top-level Apache configuration resolved the problem:

LimitUIDRange 0 2000

The description above sounds like a very similar problem.

http://blog.gaiterjones.com/send-php-mail-ubuntu-upgrade/
https://esilibrary.com/evergreen-and-koha-sitting-on-a-server/
http://mpm-itk.sesse.net/