pyesetz: (fire-hunter)
[personal profile] pyesetz
The yum update command is supposed to fix problems, not cause them.  It installs only carefully-vetted changes that merely improve security and do not change the function of any program.

Yesterday I ran yum update on company 𝔾's servers.  It found 14 updates, including one called "httpd.i386 0:2.2.3-31.el5.centos.4".

Today I got an email:
From: anonymous@Company 𝔾.com
Subject: Output from your job 97
To: apache@Company 𝔾.com

This account is currently not available.
Well, isn't that special?  I like to use the adverb "currently" a lot, but that message doesn't appear in any of my code.  A Google search says it comes from /sbin/nologin.  Apparently the update for httpd had silently "fixed" the "problem" that my system allows Apache to run batch jobs, because surely only an Evil Hacker would ever want to allow such a thing so it should just be fixed without even mentioning it.  So I edited /etc/passwd to reënable (hi, Logan!) the batch jobs, but obviously this problem will come back with the next update and next time I might not be so lucky that the email shows up soon after the update so I can connect them in my head.

There's remarkably little on the web about this.  Allowing Apache to run batch jobs is so mind-bogglingly insecure that no pundit tries to defend the practice.  For example, this page tells people to "temporarily" enable Apache logins, but is preceded by the text "NOTE !!! only change the following for testing purposes so that you can su to apache from root and test xmms !!!!" because of course there could never be any legitimate reason to do such a thing non-temporarily.  Earlier on that page, another commenter recommends using sudo, but with the proviso "Major security risk - do it only if you really need to run some commands as different users (nologin users) and if you are really lazy :)".  Apparently his preferred solution is a cronjob that runs constantly, looking for work to do.  Since when is polling to be preferred over an interrupt-driven approach?

I guess I'll write a setuid program to run the batch job as some random user.  It doesn't matter who; the batch job is already using a setuid program to read a logfile that's restricted to root, and the results are written to a MySQL table.  It'll be just another useless layer of indirection to placate some paranoid person someplace, with minimal actual increase in security.  If nobody else in the whole world allows Apache to run batch jobs, then nobody will aim a virus at that attack-vector and I'm completely safe!!!  And why is it so much more horrible to let Apache run batch jobs than to let it run programs like "batch" in the first place?

Profile

pyesetz: (Default)
Pyesetz/Песец

December 2024

S M T W T F S
1234567
891011121314
1516171819 2021
22232425262728
293031    

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 18th, 2025 02:02 pm
Powered by Dreamwidth Studios