john@wvlpdp.uucp (10/01/86)
What are people's favorite way to have cron to things as certain users. Does a "best" method exist? I have seen things like: 30 * * * * /bin/su foo < a/shell.script but does this work if user foo has a password? One method I have though off is to have cron start a set uid program that checks if the user is root or the owner of cron. The program then examines the first line of a shell script to obtain the user-id to set before fork/exec'ing /bin/sh to run the shell script. What, if anything, does this do to security etc. Sample script: # uidhere function of shell script end script Polite E-mail responses welcomed. John A. Ebersold World Video Library ihnp4!convex!ctvax!trsvax!hal6000!wvlpdp!john 2747 Airport Freeway Fort Worth, Texas 76111 (817)-831-3811
jrw@hropus.UUCP (Jim Webb) (10/03/86)
> What are people's favorite way to have cron to things as certain > users. > Does a "best" method exist? > > I have seen things like: > > 30 * * * * /bin/su foo < a/shell.script YUK! Ooops, he wants politeness :-) > but does this work if user foo has a password? Under System V (before Release 2) cron ran as root, so no passwd was needed. It is much nicer to do it like so: 30 * * * * /bin/su person -c "whatever" If you use the dash option, the /etc/profile and ~person/.profile will be read ( at least with the assumption that the Bourne shell is used). Then, you do not need to worry that this "whatever" is going to be a security problem. [Under SVR2 cron is still run as root, but individual crontabs are used, so the user id is set to the specific user before the commands are run] > > One method I have thought off is to have cron start a set uid program > that checks if the user is root or the owner of cron. Are you a Berkeley site? We SVR-er's always have cron running as root. > The program then examines the first line of a shell script to obtain > the user-id to set before fork/exec'ing /bin/sh to run the shell script. > What, if anything, does this do to security etc. > > Sample script: > # uidhere > function of shell script > > end script First off, sometimes people want binaries run from cron, and secondly, you would have to make sure root owned the file as well as all directories leading to it and that the perms are set to read-only, otherwise, this first line could be easily changed. > Polite E-mail responses welcomed. :-) -- Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw
ajs@hpfcla.HP.COM (Alan Silverstein) (10/04/86)
> It is much nicer to do it like so: > 30 * * * * /bin/su person -c "whatever" For efficiency, make that: 30 * * * * exec /bin/su person -c "exec whatever" as long as "whatever" is not a pipe.
guy@sun.uucp (Guy Harris) (10/05/86)
> It is much nicer to do it like so: > > 30 * * * * /bin/su person -c "whatever" This only works if your "su" supports "-c". I think that was a System III addition. > > > > One method I have thought off is to have cron start a set uid program > > that checks if the user is root or the owner of cron. > > Are you a Berkeley site? We SVR-er's always have cron running as root. I don't think he's a Berkeley site; it's difficult to install a UNIX system on a person :-). If he's running at a 4.3BSD site (or probably 4.2BSD; the machine with our 4.2 archival source is being cranky, so I can't check), "cron" is running as root. (Sun's version runs "cron" as "root", so it was probably that way in 4.2BSD also.) I don't remember what V7 did; it may very well have run "cron" as "daemon" or something like that. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
henry@utzoo.UUCP (Henry Spencer) (10/10/86)
> ... I don't remember what V7 did; it may > very well have run "cron" as "daemon" or something like that. Vanilla V7 did exactly that. Probably almost every V7 source licensee in the world has hacked it to run as root instead. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
paul@whuts.UUCP (HO) (10/13/86)
> > It is much nicer to do it like so: > > 30 * * * * /bin/su person -c "whatever" > > For efficiency, make that: > > 30 * * * * exec /bin/su person -c "exec whatever" > Really? Seems to me in the first case there is one exec (from cron), and in the second case there are two execs.
levy@ttrdc.UUCP (Daniel R. Levy) (10/15/86)
In article <1120001@hpfcla.HP.COM>, ajs@hpfcla.HP.COM (Alan Silverstein) writes: >> It is much nicer to do it like so: >> 30 * * * * /bin/su person -c "whatever" > >For efficiency, make that: > >30 * * * * exec /bin/su person -c "exec whatever" > >as long as "whatever" is not a pipe. And as long as "person" does not have an interactive .profile (I've been burned by this). -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy
guy@sun.UUCP (10/21/86)
> > > It is much nicer to do it like so: > > > 30 * * * * /bin/su person -c "whatever" > > > > For efficiency, make that: > > > > 30 * * * * exec /bin/su person -c "exec whatever" > > > > Really? Seems to me in the first case there is one exec (from > cron), and in the second case there are two execs. You are confused about the significance of the word "exec" in the second case. It does not cause an *extra* "exec" system call to be performed. It causes the shell *not* to perform a "fork" before the "exec". In the first case, "cron" does a "fork" and runs "/bin/sh", passing it the command line '/bin/su person -c "whatever"'. The shell then forks and runs "/bin/su", passing it the arguments "person", "-c", and "whatever". "/bin/su" then becomes the user "person", and forks and runs "/bin/sh", passing it the arguments "-c" and "whatever". "/bin/sh" now parses the command line "whatever", and, assuming it only specified one command, forks and runs that command, passing it whatever arguments "whatever" specified for it. In the second case, "cron" does a "fork" and runs "/bin/sh", passing it the command line 'exec /bin/su person -c "exec whatever"'. The shell then runs "/bin/su" without forking, passing it the arguments "person", "-c", and "exec whatever". "/bin/su" then becomes the user "person", and forks and runs "/bin/sh", passing it the arguments "-c" and "whatever". "/bin/sh" now parses the command line "exec whatever", and, assuming the "whatever" only specified one command, runs that command without forking, passing it whatever arguments "whatever" specified for it. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)