davis@pacific.mps.ohio-state.edu ("John E. Davis") (09/28/90)
Hi, I have a vt320 that I use all the time. When I logon to our system, I start up a process in the background that sleeps for a minute, checks my mailbox for newmail then just before going back to sleep, it sends the time and number of mail messages to my vt320 status line. It has worked fine so far with no problems. However, sometimes I forget to kill it before I logout. I was wondering what is the best way to put it into the background so that when I logout, it dies? I wrote the program in c, if this helps. A friend of mine once told me that when he logged on, it started writing to his terminal. Apparantly, I was once attached to that tty and left it executing when I logged out. I really do not understand this particular occurence at all. Perhaps some kind soul will tell me what happened. On another subject, One person on our system has in his home directory an executable file called 'ls'. Here it is: #! /bin/sh /bin/ls -FC echo `whoami` `hostname` `tty` `date` >> public/log exit 0 What happens, is if someone steps into this directory and types 'ls' this thing takes his picture. In principle, he could add a few more lines to copy and delete mail, etc... Although this 'ls' is harmless, it is conceivable that great damage could have been done. Is this considered a security problem? I do not advocate snooping around the system, however if one is new as I am to the unix world, then one can benifit by seeing what other people have. For example, by looking in other .emacs files, I learned alot of things about setting up the arrow keys for my terminal. Besides, isn't any file with world read access considered to be in the public domain? -- John bitnet: davis@ohstpy internet: davis@pacific.mps.ohio-state.edu
gt0178a@prism.gatech.EDU (JIM BURNS) (09/28/90)
in article <DAVIS.90Sep28015809@pacific.mps.ohio-state.edu>, davis@pacific.mps.ohio-state.edu ("John E. Davis") says: > However, sometimes I forget to kill it before I logout. I was wondering > what is the best way to put it into the background so that when I logout, it > dies? I wrote the program in c, if this helps. Seems to me that progs backgrounded w/ a plain '&' would be killed automatically when you logout. It's 'nohup'-ed procs that survive. > executable file called 'ls'. Here it is: [...] > What happens, is if someone steps into this directory and types 'ls' this > thing takes his picture. In principle, he could add a few more lines to copy Not very useful unless the intruder has '.' in his $PATH, and useless if he 'ls's that directory from another. -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
pfalstad@bow.Princeton.EDU (Paul John Falstad) (09/28/90)
In article <14228@hydra.gatech.EDU>, gt0178a@prism.gatech.EDU (JIM BURNS) writes: |> in article <DAVIS.90Sep28015809@pacific.mps.ohio-state.edu>, davis@pacific.mps.ohio-state.edu ("John E. Davis") says: |> > However, sometimes I forget to kill it before I logout. I was wondering |> > what is the best way to put it into the background so that when I logout, it |> > dies? I wrote the program in c, if this helps. |> |> Seems to me that progs backgrounded w/ a plain '&' would be killed |> automatically when you logout. It's 'nohup'-ed procs that survive. The man page for 'csh' says "all processes detached with & are effectively nohup'ed." Kind of makes you wonder why nohup exists. Try this in your favorite shell: $ csh (or whatever) % sleep 100 & % kill -HUP $$ $ ps |> > executable file called 'ls'. Here it is: |> [...] |> > What happens, is if someone steps into this directory and types 'ls' this |> > thing takes his picture. In principle, he could add a few more lines to copy |> |> Not very useful unless the intruder has '.' in his $PATH, and useless if |> he 'ls's that directory from another. Well, most people have '.' in their path (I think), but it's not to smart to have it first in your path. This only works if '.' is before /bin. |> -- |> BURNS,JIM |> Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 |> uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a |> Internet: gt0178a@prism.gatech.edu -- Here is the address to complain to: pfalstad@phoenix.princeton.edu PLink:HYPNOS GEnie:P.FALSTAD CIS: 70016,1355 That address again, sync@thumper.princeton.edu PLink:OHS738 GEnie:OHS738 CIS: 4128 143 1234 937
subbarao@phoenix.Princeton.EDU (Kartik Subbarao) (09/28/90)
In article <DAVIS.90Sep28015809@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes: >Hi, > > I have a vt320 that I use all the time. When I logon to our system, I >start up a process in the background that sleeps for a minute, checks my >mailbox for newmail then just before going back to sleep, it sends the time >and number of mail messages to my vt320 status line. It has worked fine so >far with no problems. > > However, sometimes I forget to kill it before I logout. I was wondering >what is the best way to put it into the background so that when I logout, it >dies? I wrote the program in c, if this helps. There are a few ways for doing this -- one is to use sh (yuk), another is to get the program "hup" (for csh like shells). hup will simply kill the process upon logout. A third is to get the PID of the program and then just kill -9 PID in .logout. (There are many posted ways of killing daemons). > A friend of mine once told me that when he logged on, it started writing to >his terminal. Apparantly, I was once attached to that tty and left it >executing when I logged out. I really do not understand this particular >occurence at all. Perhaps some kind soul will tell me what happened. Well - that's simple enough. If you run a program, and then log out (in csh and the normal world) -- it can still run. If it had opened the tty to write to it, under most systems it still is allowed to write to the tty afterwards. I'm sure that Dan Bernstein will attest that his pty program can stop that from happening...anyway, if the process can write to the tty, then it can put whatever it wants on it. >On another subject, One person on our system has in his home directory an >executable file called 'ls'. Here it is: > >#! /bin/sh >/bin/ls -FC >echo `whoami` `hostname` `tty` `date` >> public/log >exit 0 > >What happens, is if someone steps into this directory and types 'ls' this >thing takes his picture. In principle, he could add a few more lines to copy >and delete mail, etc... Although this 'ls' is harmless, it is conceivable >that great damage could have been done. Is this considered a security problem? >I do not advocate snooping around the system, however if one is new as I am to >the unix world, then one can benifit by seeing what other people have. For >example, by looking in other .emacs files, I learned alot of things about >setting up the arrow keys for my terminal. Besides, isn't any file with world >read access considered to be in the public domain? But his directory could be mode 711, that is, you couldn't ls the directory but only ls specific files. You know, the sad thing about this is I actually HAD an ls script in my home directory that was a really really SAD attempt to do what you say. (Good thing I wisened up FAST). There are only TWO ways that the ls script would ever be executed: a) If the person is such a fool and has "." as the first element of their path (and/or doesn't alias his commands). Then obviously ANY command that has the same name in that directory would be executed b) If the person WANTED to see if a ./ls existed and specified that. either way, it's a really sad thing to do. If you have the right path, then there is no harm in snooping. Heck, about the only way TO learn is BY snooping around. I don't know how many countless .cshrc's, .login's, .mailrc's etc I've read when I was learning how to use UNIX. Have fun. -Kartik (I need a new .signature -- any suggestions?) subbarao@{phoenix or gauguin}.Princeton.EDU -|Internet kartik@silvertone.Princeton.EDU (NeXT mail) -| SUBBARAO@PUCC.BITNET - Bitnet
pfalstad@dae.Princeton.EDU (Paul John Falstad) (09/29/90)
In article <2903@idunno.Princeton.EDU> pfalstad@bow.Princeton.EDU (Paul John Falstad) writes: >Try this in your favorite shell: > >$ csh (or whatever) >% sleep 100 & >% kill -HUP $$ >$ ps Well that was dumb of me. Of course this works in any shell, but it doesn't prove anything. The tty driver sends SIGHUP to all processes in the process group associated with the terminal when you logout. So if your login shell is sh, all your &'d processes will get killed when you logout because sh doesn't create a new process group for its children. All children of the shell have the same process group of the shell. csh creates new process groups for all the children it spawns, so they will not get the SIGHUP when the tty is closed. Sorry. -- <- Pnews isn't printing this line. Anyone know why? Here is the address to complain to: pfalstad@phoenix.princeton.edu PLink:HYPNOS GEnie:P.FALSTAD CIS: 70016,1355 That address again, sync@thumper.princeton.edu PLink:OHS738 GEnie:OHS738 CIS: 4128 143 1234 937
meissner@osf.org (Michael Meissner) (09/29/90)
In article <14228@hydra.gatech.EDU>, gt0178a@prism.gatech.EDU (JIM BURNS) writes: | The man page for 'csh' says "all processes detached with & are effectively | nohup'ed." Kind of makes you wonder why nohup exists. I believe nohup preceeded the csh. Besides real programmers use /bin/sh which does NOT do the automatic nohup'ing. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
gt0178a@prism.gatech.EDU (JIM BURNS) (09/29/90)
in article <2911@idunno.Princeton.EDU>, pfalstad@dae.Princeton.EDU (Paul John Falstad) says: >>$ csh (or whatever) >>% sleep 100 & >>% kill -HUP $$ >>$ ps > Well that was dumb of me. Of course this works in any shell, but it You also might not want to use '$$'=current shell. Try '$!' in ksh, '%1' in [ck]sh w/job control, or just use the PID reported by '&'. -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
kyriazis@iear.arts.rpi.edu (George Kyriazis) (09/29/90)
In article <DAVIS.90Sep28015809@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes: >Hi, > > I have a vt320 that I use all the time. When I logon to our system, I >start up a process in the background that sleeps for a minute, checks my >mailbox for newmail then just before going back to sleep, it sends the time >and number of mail messages to my vt320 status line. It has worked fine so >far with no problems. > > However, sometimes I forget to kill it before I logout. I was wondering >what is the best way to put it into the background so that when I logout, it >dies? I wrote the program in c, if this helps. > In your C program, send a signal 0 to your parent process (see getppid()). If kill(2) returns a -1 then the parent process (the shell in this case) has exited, so exit yourself. > A friend of mine once told me that when he logged on, it started writing to >his terminal. Apparantly, I was once attached to that tty and left it >executing when I logged out. I really do not understand this particular >occurence at all. Perhaps some kind soul will tell me what happened. > The C program inherits the tty from the parent process (the shell). ttys are, by default, writeable. So when the guy logged in, he still got the output from your program that was not killed. > On another subject, One person on our system has in his home directory an >executable file called 'ls'. Here it is: > Yes, this is a security problem. What you can do to get rid of annoyances like that is to put '.' in the end of your path. 'ls' will be found in its normal place intead of ./ls, that happens when you have '.' in the beginning of your path. ---------------------------------------------------------------------- George Kyriazis kyriazis@rdrc.rpi.edu kyriazis@iear.arts.rpi.edu
chris@mimsy.umd.edu (Chris Torek) (09/29/90)
Incidentally, the fact that backgrounded programs can continue to
access their old control terminal is a `feature' (a documented bug,
actually) of older Unix systems, including 4.3BSD and 4.3BSD-tahoe
but not 4.3BSD-reno. The new POSIX terminal interface (with a lot
of help from the vnode code) makes sure that control terminals
are no longer accessible when the session that made that terminal
a control terminal loses its session leader (typically, its login
shell).
In addition, the BSD kernel no longer attaches the first terminal
you open as your control terminal. This means that daemons need
not fork before opening terminals, but also means that programs like
xterm and Emacs that start shells on ptys need changes. Specifically,
they must do a TIOCSCTTY ioctl (Set Control TTY) and---if they want
a new session, rather than just a new process group---a setsid().
A sample change (the one I made to our local variant of Gosling Emacs)
appears below. Note that NTTYDISC is also gone.
===================================================================
RCS file: RCS/pchan.c,v
retrieving revision 3.4
retrieving revision 3.5
diff -c2 -r3.4 -r3.5
*** /tmp/,RCSt1003604 Sat Sep 29 00:51:40 1990
--- /tmp/,RCSt2003604 Sat Sep 29 00:51:42 1990
***************
*** 178,185 ****
{
register int pid;
! int channel, pgrp, len, ld;
char *ptyname, *sh;
char line[100];
! char *shell();
extern int UseCshOptionF;
extern int UseUsersShell;
--- 178,185 ----
{
register int pid;
! int channel, len;
char *ptyname, *sh;
char line[100];
! char *shell(), *sindex();
extern int UseCshOptionF;
extern int UseUsersShell;
***************
*** 195,198 ****
--- 195,199 ----
}
if (pid == 0) {
+ int i; /* short term use only (3 or 4 lines) */
#ifdef ce
fprintf(err_file, "Creating pid %d on %s\n", getpid(), ptyname);
***************
*** 202,208 ****
/* signal(SIGINT, SIG_DFL); */
/* signal(SIGQUIT, SIG_DFL); */
! if ((ld = open("/dev/tty", 2)) >= 0) {
! (void) ioctl(ld, TIOCNOTTY, 0);
! (void) close(ld);
}
(void) close(2);
--- 203,209 ----
/* signal(SIGINT, SIG_DFL); */
/* signal(SIGQUIT, SIG_DFL); */
! if ((i = open("/dev/tty", 2)) >= 0) {
! (void) ioctl(i, TIOCNOTTY, 0);
! (void) close(i);
}
(void) close(2);
***************
*** 212,218 ****
/* NOTREACHED */
}
! pgrp = getpid();
! (void) ioctl(2, TIOCSPGRP, &pgrp);
! (void) setpgrp(0, pgrp);
(void) dup2(2, 0);
(void) dup2(2, 1);
--- 213,228 ----
/* NOTREACHED */
}
! /*
! * We want a session capable of doing job control,
! * with this terminal as the control terminal.
! */
! #ifdef TIOCSCTTY
! (void) setsid();
! (void) ioctl(2, TIOCSCTTY, (char *)0);
! #else
! i = getpid();
! (void) ioctl(2, TIOCSPGRP, &i);
! (void) setpgrp(0, i);
! #endif
(void) dup2(2, 0);
(void) dup2(2, 1);
***************
*** 229,240 ****
(void) ioctl(0, TIOCSLEN, &len);
#endif
! len = UseUsersShell;
! UseUsersShell = 1;
! ld = strcmp(shell(), "/bin/csh") ? OTTYDISC : NTTYDISC;
! (void) ioctl(0, TIOCSETD, &ld);
! UseUsersShell = len;
! sh = shell();
execlp(sh, sh, UseUsersShell && UseCshOptionF ? "-cf" : "-c",
! command, (char *) 0);
(void) sprintfl(line, sizeof line,
"Couldn't exec shell \"%s\"\n", sh);
--- 239,249 ----
(void) ioctl(0, TIOCSLEN, &len);
#endif
! #ifdef NTTYDISC
! i = sindex(shell(1), "csh") ? OTTYDISC : NTTYDISC;
! (void) ioctl(0, TIOCSETD, &i);
! #endif
! sh = shell(0);
execlp(sh, sh, UseUsersShell && UseCshOptionF ? "-cf" : "-c",
! command, (char *)0);
(void) sprintfl(line, sizeof line,
"Couldn't exec shell \"%s\"\n", sh);
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain: chris@cs.umd.edu Path: uunet!mimsy!chrisgt0178a@prism.gatech.EDU (JIM BURNS) (09/30/90)
in article <+CN%|A*@rpi.edu>, kyriazis@iear.arts.rpi.edu (George Kyriazis) says: > Yes, this is a security problem. What you can do to get rid of > annoyances like that is to put '.' in the end of your path. 'ls' will > be found in its normal place intead of ./ls, that happens when you have > '.' in the beginning of your path. Or, since most people have an alias for 'ls' anyway for their favorite options, make sure it explicitly references /bin/ls. (Sh users can use functions instead, if your version supports them.) -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
brian%cirrusl@oliveb.ATC.olivetti.com (Brian Feinberg) (10/02/90)
The simplest thing to do is: Assuming you have a line like 'progname &' in your .login, put something like 'kill -9 %progname' in your .logout . What else? -- Brian -- Brian Feinberg <brian%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!brian -- Brian Feinberg <brian%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!brian
davis@pacific.mps.ohio-state.edu ("John E. Davis") (10/02/90)
|The simplest thing to do is: |Assuming you have a line like 'progname &' in your .login, |put something like 'kill -9 %progname' in your .logout . |What else? | -- Brian Actually, it is not this simple. The program is meant to be run on only those terminals which have a status line. So I would have to put 'if' statements in the .logout and it would start to get ugly and not very elegent. I finally used 'fork' to startup a child process which then looks for the presence of its parent and then exits if the parent is gone. This idea was originally suggested to me by adb@cs.bu.edu (Adam Bryant). -- John bitnet: davis@ohstpy internet: davis@pacific.mps.ohio-state.edu