Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 May 1998 05:16:36 -0400 (EDT)
From:      CyberPeasant <djv@bedford.net>
To:        freebsd-questions@FreeBSD.ORG
Subject:   /etc/crontab fishiness
Message-ID:  <199805220916.FAA17487@lucy.bedford.net>

next in thread | raw e-mail | index | archive | help
The crontab(5) man page asserts that variables declared in a crontab,
such as

HOME=/var/log

in /etc/crontab will be passed to the commands executed. In the case
at least of /etc/crontab executing the supplied /etc/weekly script,
this is not the case.

Place "echo $HOME" in that script, and see "/root", not the expected
"/var/log".

Because of this, the updatedb script, further on, will fail with
the error messages:

	shell-init: could not get current directory: \
		getcwd: cannot access parent directories
	job-working-directory: could not get current directory: \
		getcwd: cannot access parent directories

Someone asked about these within the last few days. A generally
correct answer was given, but this is the specific cause, I think:

This error occurs because the /usr/libexec/locate.updatedb script
is run later as user "nobody", and in many systems (mine, and I bet
hers, who reported this problem), root's homedir has restricted permissions,
in my case 600 or 700 depending on my mood. "nobody" can't get his
bearings with these permissions, and the command fails.

The fix is to allow world read/execute for /root (eh, when pigs
have wings, maybe ;),  or to cd to the HOME which the crontab suggests,
but does not implement.  Accomplish this by placing
	cd /var/log
before this line in /etc/weekly:
	echo /usr/libexec/locate.updatedb | nice -5 su -fm nobody 2>&1 |\
        fgrep -v 'Permission denied'

The top of the file is a place before that line. There are other su's
in there, and possibly also in /etc/daily and /etc/monthly, that may fail for
similar reasons.

This affects more systems than FreeBSD (Linux RH 4.1 is afflicted),
but I have usually just hacked it by not using the su.  Or by getting
impatient, cd'ing to /etc and doing "sh weekly". Of course, in this condition,
it /works OK/, since "nobody" can r-x /etc.

Su'ing to "nobody" is a privacy/security measure when building locate.db
in systems running with many human users.

Dave
-- 
                               Unix System 7:
      an improvement on all other Unix releases, previous and subsequent.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805220916.FAA17487>