Solaris 11.2 an cron and root...

[Gary R. Schmidt]

With 11.3 out in beta, of course it's time to move to an 11.something to
production here, so I builds me a system and starts to look around...

Okay, how do I get the root crontab to work?

The Oracular documentation does not help, implying that I need to create
a "cron.allow" with root in it, but I tried that and it didn't work.

A bit of goggling led to un-expiring the root password, with "-x -1",
but no change.

And of course using pfexec inside the administrative user's crontab
doesn't do enough. (And IIRC sudo needs a terminal.)

So, what's the secret?

Cheers,
Gary B-)

--
When men talk to their friends, they insult each other.
They don't really mean it.
When women talk to their friends, they compliment each other.
They don't mean it either.

[Casper H.S. Dik]

"Gary R. Schmidt" <grsc...@acm.org> writes:

>With 11.3 out in beta, of course it's time to move to an 11.something to
>production here, so I builds me a system and starts to look around...

>Okay, how do I get the root crontab to work?

It should work without any configuration. What are you trying and
what isn't working?

You, of course, need to edit crontabs using "crontab -e".

Casper

[John D Groenveld]

In article <j0oc7c-...@paranoia.mcleod-schmidt.id.au>,

Gary R. Schmidt <grsc...@acm.org> wrote:
>A bit of goggling led to un-expiring the root password, with "-x -1",
>but no change.
>
>And of course using pfexec inside the administrative user's crontab
>doesn't do enough. (And IIRC sudo needs a terminal.)
>
>So, what's the secret?

Try reverting root as a user:
<URL:http://docs.oracle.com/cd/E36784_01/html/E37123/rbactask-21.html>

John
groe...@acm.org

[Casper H.S. Dik]

That should not matter.

Unless root's name exists in /etc/cron.d/cron.deny, cron should be
able to run crontab and that is the default configuration.

Casper

[John D Groenveld]

In article <55a3ba7c$0$2926$e4fe...@news2.news.xs4all.nl>,

Casper H.S. Dik <Caspe...@OrSPaMcle.COM> wrote:
>>Try reverting root as a user:
>><URL:http://docs.oracle.com/cd/E36784_01/html/E37123/rbactask-21.html>
>
>
>That should not matter.
>
>Unless root's name exists in /etc/cron.d/cron.deny, cron should be
>able to run crontab and that is the default configuration.

I should have tested.
Wrongly intuited that roles can't have user at/cron jobs.

John
groe...@acm.org

[Casper H.S. Dik]

groe...@cse.psu.edu (John D Groenveld) writes:

We ship the system with root as a role and still ship it with
crontabs for root.

Let's wait until the OP responds what didn't work for him,

Casper

[Gary R. Schmidt]

On 14/07/2015 12:25 AM, Casper H.S. Dik wrote:
[SNIP]

>
> We ship the system with root as a role and still ship it with
> crontabs for root.
>
> Let's wait until the OP responds what didn't work for him,
>

Double checked /etc/cron.d/cron.deny:
$ cat /etc/cron.d/cron.deny
daemon
bin
nuucp
$

There is no /etc/cron.d/cron.allow

$ pfexec crontab -e root
Warning - Invalid account: 'root' not allowed to execute cronjobs
crontab: The audit context for your shell has not been set.
$

$ sudo crontab -e root
Warning - Invalid account: 'root' not allowed to execute cronjobs
[It then opens the crontab file, edits it, and saves it, as expected]
$

Examining /var/cron/log and olog:
! *** cron started *** pid = 1097 Sat Jun 27 18:04:16 2015
> CMD: /usr/lib/update-manager/update-refresh.sh
> root 2579 c Sat Jun 27 18:30:00 2015
! user (root) password has expired Sat Jun 27 18:30:00 2015
...
[NOTE that other users cronjobs run.]

I also put a simple "df -h" in, just in case it was something weird.

I changed nothing that I can think of that would have stopped root
cronjobs from working. Although I was fiddling, I don't recall hitting
anything cron-ish.

I installed the x64 system from a live DVD.

Apart from root cronjobs, everything works! As in, "everything that I
have tried" works. OpenCSW apache/php/mysql and others, Studio 12.4
Compiler, postfix built from source, leafnode, all the junk I lobbed
into it from my self-built /opt/local tree. Nothing points at cron!

For completeness:
$ svccfg -s cron listprop
usr dependency
usr/entities fmri
svc:/system/filesystem/local
usr/grouping astring require_all
usr/restart_on astring none
usr/type astring service
ns dependency
ns/entities fmri
svc:/milestone/name-services
ns/grouping astring require_all
ns/restart_on astring none
ns/type astring service
manifestfiles framework
manifestfiles/etc_svc_profile_generic_xml astring
/etc/svc/profile/generic.xml
manifestfiles/lib_svc_manifest_system_cron_xml astring
/lib/svc/manifest/system/cron.xml
general framework
general/action_authorization astring
solaris.smf.manage.cron
general/entity_stability astring Unstable
general/single_instance boolean true
dependents framework
dependents/cron_multi-user fmri
svc:/milestone/multi-user
startd framework
startd/ignore_error astring core,signal
start method
start/exec astring
/lib/svc/method/svc-cron
start/group astring root
start/timeout_seconds count 60
start/type astring method
start/use_profile boolean false
start/user astring root
stop method
stop/exec astring :kill
stop/timeout_seconds count 60
stop/type astring method
refresh method
refresh/exec astring ":kill -THAW"
refresh/timeout_seconds count 60
refresh/type astring method
tm_common_name template
tm_common_name/C ustring "clock daemon
(cron)"
tm_man_cron1M template
tm_man_cron1M/manpath astring /usr/share/man
tm_man_cron1M/section astring 1M
tm_man_cron1M/title astring cron
tm_man_crontab1 template
tm_man_crontab1/manpath astring /usr/share/man
tm_man_crontab1/section astring 1
tm_man_crontab1/title astring crontab

And:
$ ps -ef
UID PID PPID C STIME TTY TIME CMD
...
root 25663 1 0 Jul 05 ? 0:05 /usr/sbin/cron
...

[Casper H.S. Dik]

"Gary R. Schmidt" <grsc...@acm.org> writes:

>$ pfexec crontab -e root
>Warning - Invalid account: 'root' not allowed to execute cronjobs
>crontab: The audit context for your shell has not been set.
>$

Did you read the crontab manual page?

I think you are a victim of this:

o if Solaris Auditing is enabled, the user's shell is
not audited and the user is not the crontab owner.
This can occur if the user logs in by way of a pro-
gram, such as some versions of SSH, which does not
set audit parameters.


How did you login to the machine? Did you use the standard
SunSSH & the standard pam stack or did you use a different
ssh or some other way to login into the system so
that the auditing context is not set in your shell.

See:

>crontab: The audit context for your shell has not been set.

>Examining /var/cron/log and olog:
>! *** cron started *** pid = 1097 Sat Jun 27 18:04:16 2015
> > CMD: /usr/lib/update-manager/update-refresh.sh
> > root 2579 c Sat Jun 27 18:30:00 2015
>! user (root) password has expired Sat Jun 27 18:30:00 2015
>...
>[NOTE that other users cronjobs run.]

Ok. That is interesting; did you reset the password for root?

Typically, root's password will not expire.

What does the following command return:

getent user_attr root

>I installed the x64 system from a live DVD.

>Apart from root cronjobs, everything works! As in, "everything that I
>have tried" works. OpenCSW apache/php/mysql and others, Studio 12.4
>Compiler, postfix built from source, leafnode, all the junk I lobbed
>into it from my self-built /opt/local tree. Nothing points at cron!

Did you install your own SSH? And what is wrong with the apache
php and such delivered with Solaris? Does supported to some
extent (depends on the bit of software)

Casper

[Gary R. Schmidt]

On 15/07/2015 6:23 AM, Casper H.S. Dik wrote:
> "Gary R. Schmidt" <grsc...@acm.org> writes:
>
>> $ pfexec crontab -e root
>> Warning - Invalid account: 'root' not allowed to execute cronjobs
>> crontab: The audit context for your shell has not been set.
>> $
>
> Did you read the crontab manual page?
>
> I think you are a victim of this:
>
> o if Solaris Auditing is enabled, the user's shell is
> not audited and the user is not the crontab owner.
> This can occur if the user logs in by way of a pro-
> gram, such as some versions of SSH, which does not
> set audit parameters.
>
>
> How did you login to the machine? Did you use the standard
> SunSSH & the standard pam stack or did you use a different
> ssh or some other way to login into the system so
> that the auditing context is not set in your shell.
>
> See:
>
>> crontab: The audit context for your shell has not been set.
>

Yes, I use the OpenCSW SSHD due to internal requirements (read: security
theatre) to keep things more up to date. And I use the Xming plink.exe
to "ssh -X" into the system.

Fired up the X console, and yes, "crontab: The audit context for your
shell has not been set." no longer appears, "Warning - Invalid account:
'root' not allowed to execute cronjobs" still does.

>> Examining /var/cron/log and olog:
>> ! *** cron started *** pid = 1097 Sat Jun 27 18:04:16 2015
>>> CMD: /usr/lib/update-manager/update-refresh.sh
>>> root 2579 c Sat Jun 27 18:30:00 2015
>> ! user (root) password has expired Sat Jun 27 18:30:00 2015
>> ...
>> [NOTE that other users cronjobs run.]
>
> Ok. That is interesting; did you reset the password for root?
>
> Typically, root's password will not expire.
>
> What does the following command return:
>
> getent user_attr root
>

I had not played with the root password at that time. the first line of
/var/adm/messages.0 is: "Jun 27 07:24:59 solaris genunix: [ID 540533
kern.notice] ^MSunOS Release 5.11 Version 11.2 64-bit", which is when I
did the post-install reboot.

$ getent user_attr root
root::::type=role;auths=solaris.*;profiles=All;audit_flags=lo\:no;lock_after_retries=no;min_label=admin_low;clearance=admin_high
$

I realised that I had an earlier VBox VM of 11.2 I had set up as an AI
to install some old T1000's for dev/test roles, and the root cron works
there. (The VM had not been run up since November 2014, but there were
no errors in /var/cron/log from when it was being used.)

>> I installed the x64 system from a live DVD.
>
>> Apart from root cronjobs, everything works! As in, "everything that I
>> have tried" works. OpenCSW apache/php/mysql and others, Studio 12.4
>> Compiler, postfix built from source, leafnode, all the junk I lobbed
>> into it from my self-built /opt/local tree. Nothing points at cron!
>
> Did you install your own SSH? And what is wrong with the apache
> php and such delivered with Solaris? Does supported to some
> extent (depends on the bit of software)
>

When I was setting it up I did not know that there was an Apache 2.2
available from the repository, or PHP 5.3 and so on. Time to research
things before you do them does not happen here!

This is starting to look like it might be a wipe-and-start-over, there's
no way to do a refresh install with 11.2 is there?

[Casper H.S. Dik]

"Gary R. Schmidt" <grsc...@acm.org> writes:

>Yes, I use the OpenCSW SSHD due to internal requirements (read: security
>theatre) to keep things more up to date. And I use the Xming plink.exe
>to "ssh -X" into the system.

Apparently, the OpenCSW SSHD does not include auditing; either fix
it (not sure where auditing is set, but it supposed to be set
in pam_unix_cred. Is PAM configured for SSHD?

>Fired up the X console, and yes, "crontab: The audit context for your
>shell has not been set." no longer appears, "Warning - Invalid account:
>'root' not allowed to execute cronjobs" still does.

What does "passwd -s root" say?

>$ getent user_attr root
>root::::type=role;auths=solaris.*;profiles=All;audit_flags=lo\:no;lock_after_retries=no;min_label=admin_low;clearance=admin_high

Looks standard. You could also make it into a normal user
(even when root is a ordinary user, he still can't login unless you
modify the ssh configuration and others)

>When I was setting it up I did not know that there was an Apache 2.2
>available from the repository, or PHP 5.3 and so on. Time to research
>things before you do them does not happen here!

>This is starting to look like it might be a wipe-and-start-over, there's
>no way to do a refresh install with 11.2 is there?

Well; there is "pkg verify" and "pkg fix".

These can't generally not fix configuration files but you can remove
them and add them back.

For SMF, there is also "svccfg delcust" (remove customications for
a specific service)

Casper

[Gary R. Schmidt]

On 15/07/2015 11:08 PM, Casper H.S. Dik wrote:
[SNIP]
>

> What does "passwd -s root" say?
>

root PS

I got pissed off, fired up a new VM and did an install, bog stock, no
changes at all, and the root cron would not work.

So I started randomly looking at files, spotted that /etc/shadow looked
like this:
root:<stuff>:0::::::

See that "0" in the lastchg field? On my older VM what works, it is
16292...

So I took a gamble and changed it to 16292, now it all works.

Well, I say "all", but I cannot set the root password, it fails with:
Unexpected failure. Password file/table unchanged.
And this shows up in /var/adm/messages:
passwd[14552]: [ID 587833 user.error] passwdutil.so: can't get domain

For my current purposes, this is fine, I presume something in the
repository that used to set the lastchg field to something sensible no
longer happens.

[ucfi...@gmail.com]

For the lay person, it seems like root needs a password change prior to actually allowing cron to run. I'm totally speculating, but this sounds like an install time security feature intended to keep new installations from being completely hijacked prior to system hardening.

[ucfi...@gmail.com]

Also, I can confirm this is the same for 11.3

[YTC#1]

On 11/08/2016 16:23, ucfi...@gmail.com wrote:
> Also, I can confirm this is the same for 11.3

I've just run up an S11.3 VM

cron is running
I can crontab -e (from root)

I've gone back down the thread and can't really work out what the OP has
done to break it, other than make root a user (which IMO is a stupid
thing to do)

--
Bruce Porter
"The internet is a huge and diverse community but mainly friendly"
http://ytc1.blogspot.co.uk/
There *is* an alternative! http://www.openoffice.org/

[Gary R. Schmidt]

On 12/08/2016 02:00, YTC#1 wrote:
> On 11/08/2016 16:23, ucfi...@gmail.com wrote:
>> Also, I can confirm this is the same for 11.3
>
> I've just run up an S11.3 VM
>
> cron is running
> I can crontab -e (from root)
>
> I've gone back down the thread and can't really work out what the OP has
> done to break it, other than make root a user (which IMO is a stupid
> thing to do)
>

I'm the OP, and for the record, I did *not* make root a user.

Whatever was set in /etc/passwd et al was either the work of the
installation, or of subsequent attempts to solve the problem of the cron
not running root jobs.

That machine is dead now, anyway, and has been replaced with an 11.3
system. :-)

[YTC#1]

On 12/08/2016 05:13, Gary R. Schmidt wrote:
> On 12/08/2016 02:00, YTC#1 wrote:
>> On 11/08/2016 16:23, ucfi...@gmail.com wrote:
>>> Also, I can confirm this is the same for 11.3
>>
>> I've just run up an S11.3 VM
>>
>> cron is running
>> I can crontab -e (from root)
>>
>> I've gone back down the thread and can't really work out what the OP has
>> done to break it, other than make root a user (which IMO is a stupid
>> thing to do)
>>
> I'm the OP, and for the record, I did *not* make root a user.
>
> Whatever was set in /etc/passwd et al was either the work of the
> installation, or of subsequent attempts to solve the problem of the cron
> not running root jobs.
>

Oh well, we may never know :-(

> That machine is dead now, anyway, and has been replaced with an 11.3
> system. :-)

Which is of course working as expected.

>
> Cheers,
> Gary B-)

[ytc1]

On 14/07/2015 16:14, Gary R. Schmidt wrote:
> On 14/07/2015 12:25 AM, Casper H.S. Dik wrote:
> [SNIP]
>>
>> We ship the system with root as a role and still ship it with
>> crontabs for root.
>>
>> Let's wait until the OP responds what didn't work for him,
>>
> Double checked /etc/cron.d/cron.deny:
> $ cat /etc/cron.d/cron.deny
> daemon
> bin
> nuucp
> $
>
> There is no /etc/cron.d/cron.allow
>
> $ pfexec crontab -e root
> Warning - Invalid account: 'root' not allowed to execute cronjobs
> crontab: The audit context for your shell has not been set.

Bringing an old thread back to life ....
As it happens I hit this on Thursday, S11.4

I was convinced it was hardening.

Until I realised 2 servers had the issue on the same day.

Looked at /etc/shadow and noticed that there was a 35 day expiry st
root:<passwd>:19578::::35::811476


passwd -x didn't make any difference, so I edited shadow to remove the
last change and expire entries

It all worked again

These were 2 T8-1s, fresh (factory) install + SRU59

I have 2 more to setup next week, I'll look at the shadow file carefully ...