cronie doesn't reexec itself causing pam errors

[arekm]

Since more and more distributions are going into rolling distributions I'm rereporting this issue on github:

"
>>>> Such scenario:
>>>> - cronie is started and has some jobs run periodically; is this is
>>>> linked with
>>>> some pam libraries
>>>> - pam is upgraded to new version
>>>> - cronie is going to run job and tries to authorize it via PAM.
>>>> Unfortunately
>>>> cronie was started and is using old pam libraries while in mean time
>>>> pam was
>>>> upgraded. So old pam code tries to load new pam .so modules and that
>>>> of course
>>>> fails (new modules can be totally incompatible with old pam
>>>> libraries).
>>>>
>>>> Feb 9 13:52:01 firma /usr/sbin/crond[6592]: (root) FAILED to authorize
>>>> user
>>>> with PAM (Moduł jest nieznany)
>>>> Feb 9 13:54:01 firma /usr/sbin/crond[7282]: (root) FAILED to authorize
>>>> user
>>>> with PAM (Moduł jest nieznany)
>>>> Feb 9 13:56:01 firma /usr/sbin/crond[8037]: (root) FAILED to authorize
>>>> user
>>>> with PAM (Moduł jest nieznany)
>>>> Feb 9 13:58:01 firma /usr/sbin/crond[8718]: (root) FAILED to authorize
>>>> user
>>>> with PAM (Moduł jest nieznany)
>>>>
>>>> (Moduł jest nieznany means Module is unknown).
>>>>
>>>> It would work fine if cronie would reexec itself before running
>>>> jobs... maybe
>>>> there are other solutions.
>>>>
>>>> Anyway it's constant pain here and ususally hard to notice
>>>> immediately.
>>>> -- 



>>> Hello,
>>> this doesn't happened in "normal" stable distribution.
>>
>> That's very limited view of what's out there. There are other distributions
>> than "normal" or people even compile things themselfs without depending on
>> distributions.
>
> Hi,
>
> Just FYI - that reported cronie weakness is the most often repeated problem I
> see in last 2 years here on setups where...
>
>>
>>> API/ABI changes
>>> during release are usually forbidden.
>>
>> Here are usually allowed because we have very different approach than
>> redhat has.
>
> ... ABI changes are allowed. Counted in hundred of cases :-/
>
>>
>>> Also if I call reexec in cronie,
>>> also all other daemons should call it to live with change of API.
>>>
>>> I'm
>>> sorry, but I don't want add this change of code into cronie.
>>
>> dlopen pam libs when needed instead of linking with them then?
>
> Or better build time option to enable reexec in cronie?
>
>>
>>> Best regards,
>>> Marcela
>
>
I don't have much time for development these days. If you can send me a patch, I could include it in next version. I guess it would be needed to add option into Configure.ac and properly conditionalize the re-exec part.

Thanks,
Marcela 


"

Or if cronie detects such errors it could die with critical error instead of silently (not) working (where silently is deamon exists but doesn't run its job and only logs errors due to permanently being in fatal state).

[t8m]

I do not think re-execing cronie is something I'd like to see in the code. This seems to me like a seriously ugly workaround for not properly restarting the crond on such a breaking pam update which should be a job of properly integrated distribution.

[t8m]

BTW, such a breaking pam update should warrant full system restart as there might be also other long running processes (for example sshd and other login daemons) that are linked to libpam. And yes, the other option is to know about all long-running libpam users and restart all of them but that is quite hard to do.

[arekm]

sshd reexecs.

The only problematic program I encountered is cronie, especially it fails in a silent way (if you monitor only crond process existence and not weird cron log content).

Distro has this mechanism but it is global and is disabled locally. I guess have to find a way to never disable it for crond. Or patch cronie locally to exit() if such pam error happens.

[glensc]

With 17 years of being a rolling distro maintainer, I can confirm only crond has this problem. not just cronie, but other flavors too, because they probably have same codebase at some point, so share the design.