cron and expired root password

Jaromír Cápík <[email protected]> Tue, 10 Jan 2017 13:01:09 +0100 (CET)
Newsgroups gmane.linux.pam
Message-ID <[email protected]>
--===============5647599532430717446==
Content-Type: multipart/alternative;
	boundary="=_33369bd53bd8eea56dd3ae6e=92c1d500-4bca-5b29-95ce-a2109d5d71e7_="

--=_33369bd53bd8eea56dd3ae6e=92c1d500-4bca-5b29-95ce-a2109d5d71e7_=
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello everyone.=0A=
=0A=
I'd like to ask you a question related to pam configuration for crond.=
=0A=
=0A=
Under some circumstances we run systems with expired root password and due=
 =0A=
to various product specific reasons it is not possible to avoid that. In =
=0A=
such case the cron daemon fails with the following two messages in the cro=
n =0A=
log till a new root password is set:=0A=
=0A=
=C2=A0 /usr/sbin/cron[28121]: (CRON) pam_message (Password change requeste=
d. =0A=
Choose a new password.)=0A=
=C2=A0 /usr/sbin/cron[28121]: Authentication token is no longer valid; new=
 one =0A=
required=0A=
=0A=
=0A=
That prevents logrotate from running and leads to a state when the /var =
=0A=
partition is flooded with uncompressed product logs (eating few GB of disk=
 =0A=
space a day) and when the partition gets full, the services start failing.=
=0A=
=0A=
I tried to play with the /etc/pam.d/crond config and the addition of the =
=0A=
following line helped:=0A=
=0A=
=C2=A0 account=C2=A0 sufficient=C2=A0=C2=A0=C2=A0=C2=A0 pam_rootok.so=
=0A=
=0A=
=0A=
I also tested a second solution using the /etc/cron.allow file where the =
=0A=
root account can be added to allow cron execution with expired root =0A=
password:=0A=
=0A=
=C2=A0 account=C2=A0 sufficient=C2=A0=C2=A0=C2=A0=C2=A0 pam_listfile.so it=
em=3Duser sense=3Dallow file=3D/etc/=0A=
cron.allow onerr=3Dsucceed quiet=0A=
=0A=
=0A=
Are there any security risks of such modifications?=0A=
=0A=
Thanks in advance for any anwer.=0A=
=0A=
Best regards,=0A=
Jaromir Capik.=0A=
=0A=
--=_33369bd53bd8eea56dd3ae6e=92c1d500-4bca-5b29-95ce-a2109d5d71e7_=
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body>Hello everyone.<br><br>I'd like to ask you a question related =
to pam configuration for crond.<br><br>Under some circumstances we run sys=
tems with expired root password and due to various product specific reason=
s it is not possible to avoid that. In such case the cron daemon fails wit=
h the following two messages in the cron log till a new root password is s=
et:<br><br>&nbsp; /usr/sbin/cron[28121]: (CRON) pam_message (Password chan=
ge requested. Choose a new password.)<br>&nbsp; /usr/sbin/cron[28121]: Aut=
hentication token is no longer valid; new one required<br><br><br>That pre=
vents logrotate from running and leads to a state when the /var partition =
is flooded with uncompressed product logs (eating few GB of disk space a d=
ay) and when the partition gets full, the services start failing.<br><br>I=
 tried to play with the /etc/pam.d/crond config and the addition of the fo=
llowing line helped:<br><br>&nbsp; account&nbsp; sufficient&nbsp;&nbsp;&nb=
sp;&nbsp; pam_rootok.so<br><br><br>I also tested a second solution using t=
he /etc/cron.allow file where the root account can be added to allow cron =
execution with expired root password:<br><br>&nbsp; account&nbsp; sufficie=
nt&nbsp;&nbsp;&nbsp;&nbsp; pam_listfile.so item=3Duser sense=3Dallow file=
=3D/etc/cron.allow onerr=3Dsucceed quiet<br><br><br>Are there any security=
 risks of such modifications?<br><br>Thanks in advance for any anwer.<br><=
br>Best regards,<br>Jaromir Capik.<br><br></body></html>=
--=_33369bd53bd8eea56dd3ae6e=92c1d500-4bca-5b29-95ce-a2109d5d71e7_=--


--===============5647599532430717446==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pam-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pam-list
--===============5647599532430717446==--