[comp.unix.sysv386] SCO UNIX 3.2.2 Can't set login uid from cron

bernd@pfm.rmt.sub.org (Bernd Hennig) (04/02/91)

I have a great problem with the SCO UNIX 3.2.2 and cron. The following
is a job in /usr/spool/cron/crontabs/news:

15,30,40,00 * * * * /bin/su news -c "/usr/lib/news/bin/input/newsrun"

(at example, this is only ONE job..)

And the result is, that cron mails me:

Cron: can't set login UID

Your commands will not be executed

(on Interactive 3.2 or Microport 3.0e this works fine, on SCO UNIX 3.2.2 not..)

Who can help me...
-- 
Bernd Hennig | Eibenweg 4| 6500 Mainz | 06131/366721 | bernd@pfm.rmt.sub.org
Man sollte seinen Feinden verzeihen - aber nicht, bevor sie am Galgen haengen
                                            Heinrich Heine 1797 - 1856

sl@van-bc.wimsey.bc.ca (Stuart Lynne) (04/03/91)

In article <1991Apr02.123535.11230@pfm.rmt.sub.org> bernd@pfm.rmt.sub.org (Bernd Hennig) writes:
>I have a great problem with the SCO UNIX 3.2.2 and cron. The following
>is a job in /usr/spool/cron/crontabs/news:
>
>15,30,40,00 * * * * /bin/su news -c "/usr/lib/news/bin/input/newsrun"
>

Just use:

  15,30,40,00 * * * * "/usr/lib/news/bin/input/newsrun"

And make sure that it is in the crontab for "news". I.e.:

	crontab -u news ....

For SCO UNIX, cron set's up the proper environment for you, including the LUID. So
you don't need the "su ..." stuff.

-- 
Stuart Lynne	Computer Signal Corporation, Canada
		...!van-bc!sl 604-937-7532(voice)     	sl@wimsey.bc.ca 

em@dce.ie (Eamonn McManus) (04/03/91)

sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes:
>In article <1991Apr02.123535.11230@pfm.rmt.sub.org> bernd@pfm.rmt.sub.org (Bernd Hennig) writes:
>>I have a great problem with the SCO UNIX 3.2.2 and cron. The following
>>is a job in /usr/spool/cron/crontabs/news:
>>15,30,40,00 * * * * /bin/su news -c "/usr/lib/news/bin/input/newsrun"
>Just use:
>  15,30,40,00 * * * * "/usr/lib/news/bin/input/newsrun"
>And make sure that it is in the crontab for "news". I.e.:

As an alternative, install our SCO su replacement, which sets the luid to
the same as the uid you are su-ing to (by doing some naughty things with
/dev/kmem).

,
Eamonn

cpcahil@virtech.uucp (Conor P. Cahill) (04/04/91)

bernd@pfm.rmt.sub.org (Bernd Hennig) writes:
>I have a great problem with the SCO UNIX 3.2.2 and cron. The following
>is a job in /usr/spool/cron/crontabs/news:

>15,30,40,00 * * * * /bin/su news -c "/usr/lib/news/bin/input/newsrun"

You don't need the su here.  Any jobs in the "news" crontab will be run
with user id set to news.

>And the result is, that cron mails me:
>Cron: can't set login UID

This is because the su command wants a password (since it is not being invoked
by root, but by news) and can't get one since input is mapped to /dev/null and
it doesn't have a controll tty.
-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

macleod@cmllab.rgb.sub.org (Connor MacLeod) (04/04/91)

In article <1991Apr02.123535.11230@pfm.rmt.sub.org>
bernd@pfm.rmt.sub.org (Bernd Hennig) wrote:

| I have a great problem with the SCO UNIX 3.2.2 and cron. The following
| is a job in /usr/spool/cron/crontabs/news:
| 15,30,40,00 * * * * /bin/su news -c "/usr/lib/news/bin/input/newsrun"
| Cron: can't set login UID

Hmmm... Maybe it's the problem that "news" want's to su to news.
Have you tried the command without the "/bin/su -c"?
Are you sure you're running 3.2v2?
(Have a look at /etc/perms/rts. There should be a line like "#rel=3.2.2n")

If this all is of no help try moving the jobs to /usr/spool/cron/crontabs/root
                                                                          ^^^^
Rgds

-- 
Uwe Obst             # {connor|macleod}@cmllab.rgb.sub.org
(aka Connor MacLeod) # "Trust me, I know what I'm doing!" -- Sledge Hammer

mju@mudos.ann-arbor.mi.us (Marc Unangst) (04/04/91)

bernd@pfm.rmt.sub.org (Bernd Hennig) writes:
> Cron: can't set login UID

Lemme guess.  You killed and re-started cron, in order to get it to
re-read your crontab, right?

Bad move.  SCO Unix cron, in order to set the LUID to run jobs as
another user, has to run WITHOUT an LUID.  Since there is no way to
reset your LUID once it's set, and no way to un-set it, cron has to be
started from the rc scripts, not from a shell prompt.

If you reboot the machine, things should be fixed.  I don't know if
this is fixed if you install unx257; one would hope that it is, but
knowing SCO, I doubt it.

--
Marc Unangst               |
mju@mudos.ann-arbor.mi.us  | "Bus error: passengers dumped"
...!umich!leebai!mudos!mju | 

em@dce.ie (Eamonn McManus) (04/05/91)

mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:
>Bad move.  SCO Unix cron, in order to set the LUID to run jobs as
>another user, has to run WITHOUT an LUID.  Since there is no way to
>reset your LUID once it's set, and no way to un-set it, cron has to be
>started from the rc scripts, not from a shell prompt.

As an alternative to launching cron from rc, you can have it spawned by
init.  This is a little complicated, because the first thing the cron
daemon does is to fork itself into the background.  If you just try to
launch it from inittab, init will think it has finished immediately and
will end up launching a lot of cron daemons.  What we do here is to launch
a shell script that starts cron and then execs `pause', a program that
just does a pause() system call.  Then when we want a new cron, we kill
the existing cron and the `pause'.

By the way, 3.2.0 at least does not have a -u option to crontab, making it
really unpleasant to change the crontab for another user except by using
this technique or su-ing to that user.  If you use the default su it can
be quite hard to su to another user even if you know their password.
Luckily we have installed a replacement su too.

,
Eamonn

Here is /etc/startcron, which we invoked from /etc/inittab:
: use /bin/sh
# Start cron by removing an old FIFO and starting cron itself.
# We need this script because inittab commands are execed so there
# can't be more than one shell command.
# Aug 17 1990
rm -f /usr/lib/cron/FIFO
trap "" 2 3	# Don't let console quit and intr affect cron.
. /etc/TIMEZONE	# Probably don't need
/etc/cron
# Cron forks into the background so this script waits forever; kill the
# script when you kill cron, if you want to start a new cron.
exec /etc/pause

rwhite@nusdecs.uucp (Robert White) (04/06/91)

The "su -c" is only necessary for crontab entrys run as root.
If your system supports separate crontabs for each user the
"su -c" is unnecessary and should be removed.  The sample
entrys are presented under the "most limited system assumptions"
(IMHO) and should be modifyed as approprate.

It worked here just fine.

-- 
Robert C. White Jr.    |  The degree to which a language may be
Network Administrator  |   classified as a "living" language
National University    |  is best expressed as the basic ratio
crash!nusdecs!rwhite   |   of its speakers to its linguists.

dave@pmafire.inel.gov (Dave Remien) (04/07/91)

In article <boogie@dce.ie> em@dce.ie (Eamonn McManus) writes:
=>As an alternative to launching cron from rc, you can have it spawned by
=>init.  This is a little complicated, because the first thing the cron
=>daemon does is to fork itself into the background.  If you just try to
=>launch it from inittab, init will think it has finished immediately and
=>will end up launching a lot of cron daemons.  What we do here is to launch
=>a shell script that starts cron and then execs `pause', a program that
=>just does a pause() system call.  Then when we want a new cron, we kill
=>the existing cron and the `pause'.
=> [...]
=>Here is /etc/startcron, which we invoked from /etc/inittab:
=>: use /bin/sh
=># Start cron by removing an old FIFO and starting cron itself.
=># We need this script because inittab commands are execed so there
=># can't be more than one shell command.
=># Aug 17 1990
=>rm -f /usr/lib/cron/FIFO
=>trap "" 2 3	# Don't let console quit and intr affect cron.
=>. /etc/TIMEZONE	# Probably don't need
=>/etc/cron
=># Cron forks into the background so this script waits forever; kill the
=># script when you kill cron, if you want to start a new cron.
=>exec /etc/pause

Instead of the pause, why not:

sleep 2  # give cron time to fork and settle down
exec wait_on `ps -e | grep cron | awk '{print $1}'`



Where wait_on.c is:

main(argc, argv)
int argc;
char *argv[];
{
	int proc_pid;
	proc_pid = atoi(argv[1]);
	while(!kill(proc_pid, 0))sleep(1);
}

At least you only have to croak the cron, that way.

Dave
-- 
Dave Remien +*+*+*+*+*+*+*+*+*+*+*+*+*+*+ WINCO Computer Engineering Group 
  dave@pmafire.inel.gov or rzd@inel.gov      "Dave Barry for President"