Cron and lockout accounts

[Henry Cheung]

It appeared that cron will execute user jobs even when lockout is flagged in the TCB. Is there a man page or document to confirm this behaviour ? I looked for a while but cannot come across any.

We have HP-UX 11.11

[OldSchool]

I'd think it would behave that way, as cron doesn't login.

you could always create a dummy / test account, set up a test cron job (simple "date" should suffice), diable the account and see what happens.

[Henry Cheung]

I prefer a piece of written HP documentation to collaborate this HP-UX behaviour. As this is will be a gotcha for us multi-vendor unix sysadmin.

[OldSchool]

hmmm...what you prefer and what is available may be disjoint.

what's to prevent *you* from observing behaviour AND THEN documenting the observed results???

[Bill Hassell]

cron never logs in because it is never interactive. cron is run as root and schedules processes on behalf of user IDs with crontab entries. The only time a user's login state is tested is when a user logs in or starts a batch shell.

[Johnson Punniyalingam]

>>It appeared that cron will execute user jobs even when lockout is flagged in the TCB. Is there a man page or document to confirm this behaviour ? I looked for a while but cannot come across any.<<

No It will not >> It will result in cron.log<<,
has "BAD User" if your account got any problem

[Bill Hassell]

> No It will not >> It will result in cron.log<<,
> has "BAD User" if your account got any problem

Doesn't seem to be in cron, at least for 11.11. An administrator lock for a user ID still allows cron to schedule jobs for the user. Running strings on /usr/sbin/cron doesn't have the word "bad". This seems to be a Solaris feature.

[Johnson Punniyalingam]

>> This seems to be a Solaris feature<<

Oops, my BAD - sorry for any inconvenience caused :(

Thanks >>Bill<< for correcting me :)

[Henry Cheung]

TCB is a complex extension.
getprpw(1M) indicate 7 lockout flags

1 past password lifetime
2 past last login time (inactive account)
3 past absolute account lifetime
4 exceeded unsuccessful login attempts
5 password required and a null password
6 admin lock
7 password is a *

I understand there are times we need accounts that are not meant to be login.

Perhaps for file ownerships.
Perhaps purely for the perpetual execution of scheduled jobs in less-than root privivlege.

My initial quest for documentation make sure I did not miss any configurable variables that can alter cron's behaviour.

I think cron should be more refine to check the lockout flag. E.g. for bit 3 and bit 6, IMO, cron should not continue running the user's cron. But then this is debatable and that is not my intention.

I shall live with what I got.
Thanks everyone.