goldfarb@ucf-cs.UUCP (07/20/83)
A recent problem here underscores the need for cron to run programs
under effective id's other than root; there is no mechanism in cron
to permit that. I can envision a simple hack to cron.c that would
add two fields to crontab for specifying uid and gid under which the
program on the given line would be run. Before I start hacking away,
has anyone done this? Also, are there any other worthwhile enhancements
to cron.c out there?
Oh, yes, we are running 4.1bsd on an 11/780.
Ben Goldfarb
University of Central Florida
uucp: duke!ucf-cs!goldfarb
ARPA: Goldfarb.ucf-cs@Rand-Relay
--
Ben Goldfarb
uucp: {decvax,duke}!ucf-cs!goldfarb
ARPA: goldfarb.ucf-cs@Rand-Relaygoldfarb@ucf-cs.UUCP (07/20/83)
A recent problem here underscores the need for cron to run programs
under effective id's other than root; there is no mechanism in cron
to permit that. I can envision a simple hack to cron.c that would
add two fields to crontab for specifying uid and gid under which the
program on the given line would be run. Before I start hacking away,
has anyone done this? Also, are there any other worthwhile enhancements
to cron.c out there?
Oh, yes, we are running 4.1bsd on an 11/780.
--
Ben Goldfarb
uucp: {decvax,duke}!ucf-cs!goldfarb
ARPA: goldfarb.ucf-cs@Rand-Relaychris@umcp-cs.UUCP (07/22/83)
We have a program called "user" (I think this was sent over
net.sources), which we use to run as someone other than uid 0, gid 0
from crontab, e.g.
10 6 * * * /usr/local/user news /usr/lib/news/news.daily.sh
User is similar to su, except that it (a) understands groups and (b)
allows a command to follow the user:group specifier. It also changes
ownership of your terminal. Our version even handles suspending
processes, changing terminal ownership back and forth.
I suppose I can send it to ARPA sites that don't get net.sources.
- Chris
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs
ARPA: chris.umcp-cs@UDel-Relaythomson@utcsrgv.UUCP (Brian Thomson) (07/22/83)
The way to get cron to run programs as someone other than root is
to do this:
* 4 * * * su otheruser < commandfile
--
Brian Thomson, CSRG Univ. of Toronto
{linus,ihnp4,uw-beaver,floyd,utzoo}!utcsrgv!thomsondpk@brl-vgr@sri-unix.UUCP (07/22/83)
From: Doug Kingston <dpk@brl-vgr>
On our pdp-11's we modified cron to have a username field prior
to the command. In the interest of compatability we did not do this on
the Vaxes. Instead, we wrote a program called "alias" which is used
like nohup or nice (e.g. "alias user programs args ...") which if run
by the superuser (like from crontab) will run the given program as the
specified user. All you need to is add "alias user " to the fron of the
command string in the crontab entry.
Cheers,
-Doug-
PS. The following is alias.c. Enjoy!
/*
* A L I A S . C
*
* To compile: cc alias.c -O -o alias
*
* This program allows the superuser to run a program with
* arbitrary arguments with the uid/gid of any account on
* the system. If no program is specified, /bin/sh is
* assumed.
*
* % alias <account-name> [<program>[<args...>]]
*
* R E V I S I O N H I S T O R Y
*
* 05/20/78 RNJ Any program may be run, not just shell.
* New /etc/passwd lookup function.
*
* 10/25/81 DPK Converted to integer UIDs and GIDs & LIB7.
*
* 12/23/81 RSM Fixed to not "blow away" V7 environment.
* Default case now sets argv[0] to "-Alias(account)"
*/
#include <stdio.h>
#include <pwd.h>
char namebuf[30]; /* Argument 0 to new shell */
main(argc, argv)
char **argv;
{
register char *program; /* name of program to be exec ed */
register struct passwd *pw;
if( argc <2 ) {
printf("Usage: %s account [<program> [<args>]]\n", argv[0]);
exit(1);
}
if ((pw = getpwnam(argv[1])) == 0) {
printf("%s: account not found\n", argv[1]);
exit(2);
}
if (setgid( pw->pw_gid ) < 0)
perror ("setgid");
if (setuid( pw->pw_uid ) < 0)
perror ("setuid");
if( argc <= 2 ) {
program = "/bin/sh";
printf("UID = %d; GID = %d\n", pw->pw_uid, pw->pw_gid);
sprintf(namebuf, "-Alias(%s)", argv[1]);
execl(program, namebuf, 0);
} else {
program = argv[2];
argv[argc] = 0;
execv(program, &argv[2]);
}
perror(program);
exit(3);
}johnl@ima.UUCP (07/23/83)
#R:ucf-cs:-99300:ima:20400012:000:336 ima!johnl Jul 22 12:05:00 1983 (The question is asked how to run programs from "cron" under uids other than the root.) On USG Unix at least, you can put in entries like 1 2 3 4 5 su joeuser command args since the "su" command doesn't need a password if you're already the root. This seems easier than trying to build the feature into cron. John Levine, ima!johnl
mjl@ritcv.UUCP (Mike Lutz) (07/23/83)
Our cron.c (4.1 & locally mucked with V7) supports the following additions:
1. The uid & gid of a command can be specified in parentheses
just before the command itself, e.g.
(107,81)foobar
will run foobar with uid = 107 and gid = 81. Normally the
command runs with uid & gid set to an innocuous daemon user
and group (i.e., you have to explicitly request execution
with root permissions).
2. If the command name is preceded by a '#', the C shell is used
rather than the Bourne shell to parse and execute the command.
Quite frankly, I thought this was a "standard hack" we'd gotten from
somewhere along the way, but apparently one of the other wizards around
here added it. When I find out who did it, I'll give credit.
Let me know if you'd like to see the changes. If there's enough
interest, I'll post the necessary mods to net.sources, otherwise I'll
mail them individually.
Mike Lutz
{allegra,seismo}!rochester!ritcv!mjlpdl@root44.UUCP (Dave Lukes) (08/03/83)
Yawn, yawn: we run standard system III here, which has the same cron that all you 4.1BSD people have, and we run programs under all sorts of UIDs by using su. (This is very easy under SIII, since su will given any extra args it's given to the shell it runs, thus you can say `su bin -c "any command you like"'. Even with 4.1BSD you can do the same thing with `su bin <filename', I suspect. (Or maybe even `su bin <<!command1%command2%!' for all you cronophiles !). BTW: what about having a kludge to allow arbitrary GIDs as well as UIDs for commands to run under. So: who needs a new cron (or indeed anything new)? (BTBTW: while you're thinking about cron how about the following bug, which has existed since before the dark ages ?: cron only consults the time ONCE, when it starts: if it's wrong, crons idea of the time STAYS wrong forever. Yuk. It's an easy fix, and while you're at it you can get it to sleep until the next jobs got to be done, thus saving it looking in the table every minute when it knows perfectly well that there's absolutely nothing to do. And while you're doing that you can speed up the table search .... ad infinitum). Enjoy ! Dave Lukes (...!vax135!ukc!root44!pdl)
rich@cfib.UUCP (08/05/83)
#R:ucf-cs:-99300:cfib:11100003:000:600 cfib!rich Aug 3 22:17:00 1983 We have a cron.c that does just what you asked, and more. Specifically: * it fixes a cron bug with long command lines (over 100 chars) when the command line is read when there are just over 100 chars left in the buffer pool. * it allows setting the user and group id * it allows logging on a per-command basis of the output of the commands The command field may start with $uid[,gid] and/or '>', which writes stdout and stderr of the command into a logfile defined in cron.c. If this message is not too late and you are interested, let me know. Rich Baughman ...decvax!cca!ima!cfib!rich
mark%umcp-cs@udel-relay@sri-unix.UUCP (08/07/83)
From: Mark Weiser <mark%umcp-cs@udel-relay> (BTBTW: while you're thinking about cron how about the following bug, which has existed since before the dark ages ?: cron only consults the time ONCE, when it starts: if it's wrong, crons idea of the time STAYS wrong forever. E.g., once our vax thought it was 1972 after a DEC ECO. I naively changed the date after people had been running for a while, and it only took cron about 5 minutes to spawn so many processes everything was on its knees (including me praying for mercy).