[arch-general] update today causes avantfax_hourly cron: Exec format error?

[Eli Schwartz]

On 8/26/18 5:49 AM, David C. Rankin wrote:
> On 08/26/2018 03:37 AM, Ralph Corderoy wrote:
>>>> Testing manually works fine:
>>>>
>>>>   # ./phb.php
>> It's not getting that far.
> 
> I bet you would as root. The file is actually http:http owned, e.g.
> 
>   -rwxr-xr-x 1 http http 988 Sep 14  2016 /srv/http/avantfax/includes/phb.php
> 
> So running as root has no problem. Running as any other user (other than http)
> now invokes the error that is the basis for this thread. That's why it is hard
> to put my finger on the cause, unless the linux-firmware update tightened
> security in some manner so that the cron user no longer can run as http
> causing the job to fail.

That's literally not how Linux permissions work. In fact, I'm not aware
of any operating system on which that *is* how file permissions work.

You did not get a "permission denied" error. You got a "failed to exec
/etc/cron.hourly/avantfax_hourly: Exec format error".

And thusly, you're completely missing Ralph's point here.

The error message states "failed to exec
/etc/cron.hourly/avantfax_hourly". It is saying the *file*
avantfax_hourly is itself the invalid executable file.

Which makes sense because "run-parts runs all the executable files named
within constraints described below, found in directory directory."

Why do you think run-parts "should" execute this file as a cron script?
Is there some wonderful shebang in the "avantfax_hourly" file which says
"execute this script as a cron executable"?

> If you (as root, or http) call /srv/http/avantfax/includes/phb.php, it will
> silently run normally and exit with a 0 exit code. Running with any other user
> cause about 100 fopen (foo/bar/...) messages to scroll by and a returned exit
> code of 1.

That sounds like a completely different problem, since by executing the
.php file you actually execute the php file, whereas by executing the
crontab(5) file you get a case where programs determine on their own how
to treat an executable file, in this case by failing to find a shebang
line or an ELF header and complaining that it isn't a valid executable
-- I will note that this actually uses execl/execve to directly execute
the file, returning ENOEXEC *because it doesn't have a valid shebang*
and does not use execlp/execvp which emulate shells like
sh/csh/ksh/bash/zsh in attempting to fall back on executing the shell
/bin/sh with the executable file as the first argument.

...

In summary, if you tried to execute /etc/cron.hourly/avantfax_hourly
rather than run-parts /etc/cron.hourly/avantfax_hourly, you would get
the entirely different effect of it attempting to fallback on executing
/bin/sh /etc/cron.hourly/avantfax_hourly, then failing with a return
code of 1:

/etc/cron.hourly/avantfax_hourly: line 2: 0: command not found

Because the "0" in that cron invocation is not, in fact, valid as the
argv0 of a shell command.

> I have run this server for years and years, no problems, until today after
> updates. I changed nothing on the system other than 'pacman -Syu'. That what
> has me bewildered...

Color me equally bewildered, since the manpage of run-parts(1)
emphatically declares that this shall never, ever, ever work under any
conditions whatsoever.

I'm assuming that you're running anacron, not run-parts.

anacron will in fact run, on an hourly schedule, all executables in
/etc/cron.hourly/ and will use run-parts (which is designed to "execute
all executables in a directory") to, well, execute all executables in
that directory.

anacron, is a thing which is configured using a valid crontab(5)
containing cron invocations... to run `run-parts /etc/cron.hourly/`

Once again, your attempt to install crontabs as executables is the
problem here. Unless you either misremembered the events of the day when
you stated "I changed nothing on the system other than 'pacman -Syu'",
or your -Syu updated a program that of its own volition used to execute
anacron and now executes run-parts, I don't see what the issue is here.

But I'm pretty sure casting the blame on CPU microcode updates is pretty
darn erroneous no matter what.

I think you changed something long before that, then compared the time
when anacron was scheduled to begin running your invalid file, to the
time you did an -Syu, and somehow decided that the two were related.
They are not. If you change something, and anacron breaks, but anacron
does't run until an hour later by which point you've already -Syu'ed
again and updated linux-firmware, it's... understandable that the
timestamps for a program designed for *delayed execution* would match up
to something completely and utterly irrelevant.

Mind you, this is just a guess. The only thing I know for sure is that
your real problem is exactly what Ralph said it was.

You're installing a crontab designed to run every hour, into a location
meant to be run as an executable (by anacron which runs every hour).

Please re-read the cron(8), anacron(8), and crontab(5) manpages to see
where you went wrong.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20180826/4f63f70a/attachment.asc>