Product
Solaris 9 Operating System
Solaris 8 Operating System

Bug Id
4457028, 4712958

Date of Resolved Release
26-JUN-2003

Impact

Users who log in to Solaris 8 or 9 systems with Basic Security Module (BSM) enabled (bsmconv(1M)) via a third-party mechanism (e.g. OpenSSH), will no longer be able to successfully execute cron(1M) or at(1) jobs.

Contributing Factors

This issue can occur in the following releases:

SPARC Platform

• Solaris 8 without patches 109007-08 and 108875-13
• Solaris 9 without patch 114332-02

x86 Platform

• Solaris 8 without patches 109008-08 and 108876-13
• Solaris 9 without patch 114334-02

A system has BSM enabled if the following line appears in the "/etc/system" file:

   set c2audit:audit_load = 1

Note: Solaris 2.6 and 7 are not affected by this issue.

Note: Solaris 8 SPARC patch 108875-13 has been obsoleted by 109007-10 and later and Solaris 8 x86 patch 108876-13 has been obsoleted by 109008-10 and later.

Symptoms

cron(1M) or at(1) jobs issued from a user who has logged in via a third-party login mechanism will fail. In the following example, user "sunuser" has logged in via a third-party Secure Shell (SSH) program and ran "crontab -e" to schedule the "/usr/bin/date" command to be run by cron(1M):

    # tail /var/cron/log
CMD: /usr/bin/date
sunuser 304 c Tue Jun 17 09:53:00 2003
! cron audit problem. job failed (/usr/bin/date) for user sunuser Tue Jun 17 09:53:00 2003
sunuser 304 c Tue Jun 17 09:53:00 2003 rc=1

The crontab ancillary file for the affected user which is used by BSM/auditing on Solaris systems will look similar to the following (containing "0" values):

    # cat /var/spool/cron/crontabs/sunuser.au
4294967294
0
0
0
0
0 0 0 0
0

Workaround

Systems which have encountered this issue can restore cron(1M) functionality for affected users by having them log in to the system via a Sun login mechanism (console login, dtlogin, /bin/login, etc.), executing the "crontab -e" command and then saving the file. No changes are required to be made to the file. After running "crontab -e" and saving the file, the user's crontab(1) ancillary file will now contain positive values instead of zeros:

    # cat /var/spool/cron/crontabs/sunuser.au
1001
1800
1800
3f31301
4
81dec142 0 0 0
318

Resolution

This issue is addressed in the following releases:

SPARC Platform

• Solaris 8 with patch 109007-08 and 108875-13 OR 109007-10 or later
• Solaris 9 with patch 114332-02 or later

x86 Platform

• Solaris 8 with patch 109008-08 and 108876-13 OR 109008-10 or later
• Solaris 9 with patch 114334-02 or later

Note: Solaris 8 SPARC patch 108875-13 has been obsoleted by 109007-10 and later and Solaris 8 x86 patch 108876-13 has been obsoleted by 109008-10 and later.

Modification History

References

109007-08
109008-08
108875-13
108876-13
109007-10
109008-10
114332-02
114334-02




Attachments

This solution has no attachment