User cron jobs on OneFS 8.0

[John Beranek - PA]

Hi,

I've been trying to configure an AD user's crontab to run a scheduled task to run rsync to a set of remote hosts to copy data to the Isilon, and hitting unexpected problems.

When my synchronisation script (which runs rsync over SSH) runs in an interactive shell, it works fine, but when run from a nightly cron, I get errors from rsync/SSH:

Host key verification failed.

rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]

rsync error: error in rsync protocol data stream (code 12) at io.c(605) [Receiver=3.0.9]

rsync returned error '3072'

I finally tracked down what was causing this error, using truss, and found that rsync/SSH is getting Permission denied when trying to read from the user's ".ssh" directory:

62769: open("/home/AD/user/.ssh/known_hosts",O_RDONLY,0666) ERR#13 'Permission denied'

The permissions on the directory are a synthetic ACL:

$ ls -led /home/AD/user/.ssh

drwx------ 2 AD\user  wheel  196 25 Oct 12:59 /home/AD/user/.ssh

 OWNER: user:AD\use

 GROUP: group:wheel

 SYNTHETIC ACL

 0: user:AD\user allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child

 1: group:wheel allow std_read_dac,std_synchronize,dir_read_attr

but full ACEs for the known_hosts file:

$ ls -led /home/AD/user/.ssh/known_hosts

-rwxrwxr-- 1 AD\user  wheel  13251  7 Nov 13:29 /home/AD/user/.ssh/known_hosts

 OWNER: user:AD\user

 GROUP: group:wheel

 0: group:AD\isilon admins allow file_gen_all,object_inherit,container_inherit

 1: user:AD\user allow file_gen_read,file_gen_write,std_write_dac

 2: group:wheel allow file_gen_read

 3: everyone allow file_gen_read

Does anyone know why a user's cron would have a different context than an interactive shell, or if there is a way around it?

I'd prefer not to use another server to perform the synchronisations if possible.

Cheers,

John

[Chris Pepper]

John,

cron runs with a limited set of environment variables, but you can set many of them either in the crontab or in the script that runs rsync.

Chris

> Several environment variables are set up automatically by the cron(8)
> daemon. SHELL is set to /bin/sh, PATH is set to /usr/bin:/bin, and
> LOGNAME and HOME are set from the /etc/passwd line of the crontab's
> owner. HOME, PATH and SHELL may be overridden by settings in the
> crontab; LOGNAME may not.
>
> (Another note: the LOGNAME variable is sometimes called USER on BSD sys-
> tems... On these systems, USER will be set also).
>
> In addition to LOGNAME, HOME, PATH, and SHELL, cron(8) will look at
> MAILTO if it has any reason to send mail as a result of running commands
> in ``this'' crontab. If MAILTO is defined (and non-empty), mail is sent
> to the user so named. MAILTO may also be used to direct mail to multiple
> recipients by seperating recipient users with a comma. If MAILTO is
> defined but empty (MAILTO=""), no mail will be sent. Otherwise mail is
> sent to the owner of the crontab. This option is useful if you decide on
> /bin/mail instead of /usr/lib/sendmail as your mailer when you install
> cron -- /bin/mail does not do aliasing, and UUCP usually does not read
> its mail.

> --
> You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Peter Serocka]

Compare the outputs of
isi auth id
from user’s ssh session and from user’s cron job.

I’d the suspect the cron job doesn’t run with the expected
credentials (“token”) for the AD user.
That would explain the 'Permission denied’ error.

hth
— Peter

[John Beranek - PA]

Peter, you've hit the nail on the head there...in the interactive shell I get:

Ids

--------------------------------------------------------------------

ID Type          ID

--------------------------------------------------------------------

UID              UID:12345

User SID         SID:S-1-5-21-1111111111-2222222222-3333333333-4444

GID              GID:67890

Group SID        SID:S-1-5-21-5555555555-6666666666-7777777777-888

On Disk User ID  UID:12345

On Disk Group ID GID:67890

Additional ID    SID:S-1-5-21-etc-etc

                 SID:S-1-5-21-etc-etc

                 SID:S-1-5-21-etc

...

                 GID:987654

                 GID:567890

Privileges

-----------------------------------------------------

ID                      Name               Access

-----------------------------------------------------

ISI_PRIV_LOGIN_CONSOLE  Console            Read only

ISI_PRIV_LOGIN_PAPI     Platform API       Read only

ISI_PRIV_LOGIN_SSH      SSH                Read only

ISI_PRIV_SYS_SHUTDOWN   Shutdown           Read only

...

Zone Information

----------------------------------------------------------------------

Zone ID  ZID  Protocol  Local Address  Remote Address  Ifs Restricted

----------------------------------------------------------------------

System   1    17        10.20.30.10    10.30.40.50   False

----------------------------------------------------------------------

However, when run via cron, all evidence of the SIDs is gone:

Ids

--------------------------

ID Type          ID

--------------------------

UID              UID:12345

User SID         -

GID              GID:67890

Group SID        -

On Disk User ID  UID:12345

On Disk Group ID GID:67890

Additional ID    GID:987654

                 GID:567890

...

Privileges

-----------------------------

Privilege  ID   Name  Access

-----------------------------

-          -    -     -

-----------------------------

Total: 1

Zone Information

----------------------------------------------------------------------

Zone ID  ZID  Protocol  Local Address  Remote Address  Ifs Restricted

----------------------------------------------------------------------

System   1    -         -              -               False

----------------------------------------------------------------------

Total: 1

I wonder if I could get back the login token by running "sudo -u user" in the cron, with an appropriate NOPASSWD sudoers entry...

John

[John Beranek - PA]

Well, sadly it looks like 'sudo' is another thing that doesn't work in a user cron job.

John

[Chris Pepper]

Try the full path to sudo.

[Peter Serocka]

Seems you have edited alls ids for obvious reasons,
but do UIDs (and GIDs) actually match for both cases?

Then you could try replacing ACLs by plain POSIX (UNIX) permissions accordingly
for the home dir, .ssh and file .ssh

— Peter