cron & file permissions

[Mike McClain]

Howdy,

I've a cron job run daily from /etc/crontab,
the entry looks like this:
0 2 * * * root [ -d /mc/bin ] && /mc/bin/daily;

/mc/bin/daily sets umask
umask 037 # save files rw owner, group read only

then runs a script like so:
[ -e /mc/bin/secure ] && /mc/bin/secure 2>&1 | tee /root/sysstats/secure.log ;

but the permissions on secure.log come out 600:
root@/deb60:~> ls -l sysstats/secure.log
-rw------- 1 root root 67832 Jul 18 02:01 sysstats/secure.log

What do I need to do to make secure.log permissions come out 640?

Thanks,
Mike

[Bob Proulx]

Post by Mike McClain
I've a cron job run daily from /etc/crontab,

Instead of using the BSD-style interface let me strongly encourage you
to start using the newer Vixie-cron-style interface of /etc/cron.d/
where they can be separate and individual files. That way the file
can be dropped into place on a new installation or removed when
cleaning up. That is easier and cleaner than manually editing the
/etc/crontab file and working around the existing entries.

Post by Mike McClain
0 2 * * * root [ -d /mc/bin ] && /mc/bin/daily;

Okay.

Post by Mike McClain
/mc/bin/daily sets umask
umask 037 # save files rw owner, group read only
[ -e /mc/bin/secure ] && /mc/bin/secure 2>&1 | tee /root/sysstats/secure.log ;

Okay. But why the extra ';' at the end? It feels like a dangling
something that should have been edited out with some previous edit.

Post by Mike McClain
-rw------- 1 root root 67832 Jul 18 02:01 sysstats/secure.log
What do I need to do to make secure.log permissions come out 640?

I cannot recreate this behavior. Works for me. If I set up an
equivalent then I produce files with mode -rw-r-----.

To debug this, I would trace the operation of your script. First add
the printing of the current umask just before the 'tee'. Also ensure
that the target of the tee command does not exist, since umask will
only affect the creation of new files.

umask 037
umask
ls -ld /root/sysstats/secure.log
[ -e /mc/bin/secure ] && /mc/bin/secure 2>&1 | tee /root/sysstats/secure.log

I assume it is a #!/bin/sh script? If so then run it like this:

sh -x /mc/bin/daily

Then look at the trace and verify that umask is actually getting set.
Seems like there is something happening that isn't known that is not
what you expect to be happening.

Bob

[Mike McClain]

Hi Bob,

Post by Bob Proulx

Post by Mike McClain
I've a cron job run daily from /etc/crontab,

Instead of using the BSD-style interface let me strongly encourage you
to start using the newer Vixie-cron-style interface of /etc/cron.d/
where they can be separate and individual files. That way the file
can be dropped into place on a new installation or removed when
cleaning up. That is easier and cleaner than manually editing the
/etc/crontab file and working around the existing entries.

I've only added 3 lines to crontab and haven't seen any way to get files
in /etc/cron.d/ run at specific times.
I can see how /etc/cron.d/ helps developers who want their packages
cron jobs run but don't see how it would benefit me who have physical
access to the hardware.

<snip>

Thanks for your thoughts,
Mike

[Bob Proulx]

... and haven't seen any way to get files in /etc/cron.d/ run at
specific times.

The format of the /etc/cron.d/ files is the same format as the
/etc/crontab. Whatever lines you would put into /etc/crontab you
would simply put into a file in /etc/cron.d instead. No difference.
For example a /etc/cron.d/local-myscript file:

# Run mylocalscript every hour.
0 17 * * * root /usr/local/bin/mylocalscript

I can see how /etc/cron.d/ helps developers who want their packages
cron jobs run but don't see how it would benefit me who have physical
access to the hardware.

I don't see how physical access to the hardware changes things. The
advantage is that upon system upgrades any changes to /etc/crontab
will need to be merged. Local changes and system changes are both to
the same file. When dpkg encounters this it will prompt you with what
to about the merge. It is fairly easy to edit the file then and fix
things up appropriately. But if a /etc/cron.d/local-myscript file is
used instead then there is never a conflict and no merging is
needed. It is completely automatic and hands-off in that case.

So in summary the advantage is that it avoids manual interaction. It
avoids needing to merge local changes with system changes. It is
simply easier that way.

Bob

[Bob Proulx]

Post by Bob Proulx
# Run mylocalscript every hour.
0 17 * * * root /usr/local/bin/mylocalscript

That is what I get for constructing an example in a rush. Obviously
that comment doesn't match. Oh well. You get the idea.

Bob

[Mike McClain]

Hi Bob,

OK I'll try it but have a question.

Post by Bob Proulx

... and haven't seen any way to get files in /etc/cron.d/ run at
specific times.

The format of the /etc/cron.d/ files is the same format as the
/etc/crontab. Whatever lines you would put into /etc/crontab you
would simply put into a file in /etc/cron.d instead. No difference.

<snip>

man cron says:
'In general, the admin should not use /etc/cron.d/, but use the
standard system crontab /etc/crontab.'

I called it /etc/cron.d/local and from reading 'man run-parts' description
of file names think that is not going to be a problem. True?

< very clear explanation snipped >

Thanks,
Mike

[Bob Proulx]

'In general, the admin should not use /etc/cron.d/, but use the
standard system crontab /etc/crontab.'

I can only most strongly disagree with that sentiment! :-)

I hadn't ever seen that message before. Considering the fact that
Paul Vixie hasn't released nor authorized a release since the early
1990's and that all development since has happened in the various
distros I don't think that comment is authoritative anymore. And
there isn't really a single authority to say one way or the other. In
the end you will have to use your best judgement.

I called it /etc/cron.d/local and from reading 'man run-parts' description
of file names think that is not going to be a problem. True?

No Debian package would ever name their file "local". So that avoids
any name collision. I usually end up with several different files and
I name each of them something starting with "local" so as to make it
obvious that they are mine and not part of a package. Using a naming
convention to avoid a file name overlap is the only concern.

Bob

[Chris Davies]

Post by Mike McClain
/mc/bin/daily sets umask
umask 037 # save files rw owner, group read only
[ -e /mc/bin/secure ] && /mc/bin/secure 2>&1 | tee /root/sysstats/secure.log

You want the output to go to the cron email as well as to the log file?

Post by Mike McClain
-rw------- 1 root root 67832 Jul 18 02:01 sysstats/secure.log
What do I need to do to make secure.log permissions come out 640?

The permissions from umask are only applied to files that are created. If
sysstats/secure.log already exists they won't be changed.

Either delete the file and wait for your cron job to re-create it,
or fix up the permissions manually.

Chris

[Mike McClain]

Hi Chris,

Post by Chris Davies

Post by Mike McClain
/mc/bin/daily sets umask
umask 037 # save files rw owner, group read only
[ -e /mc/bin/secure ] && /mc/bin/secure 2>&1 | tee /root/sysstats/secure.log

You want the output to go to the cron email as well as to the log file?

Yes.

Post by Chris Davies

Post by Mike McClain
-rw------- 1 root root 67832 Jul 18 02:01 sysstats/secure.log
What do I need to do to make secure.log permissions come out 640?

The permissions from umask are only applied to files that are created. If
sysstats/secure.log already exists they won't be changed.

This was the clue I needed!
There was a call to 'savelog -p' before the /mc/bin/secure call and
that was creating an empty secure.log with the permissions of the previous.

Thanks for the help.
Mike