Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cos!fetter
From: fetter@cos.com (Bob Fetter)
Newsgroups: comp.arch
Subject: Re: Ignorance speaks loudest (was:Computers for users not programmers)
Message-ID: <43615@cos.com>
Date: 11 Feb 91 20:58:55 GMT
References: <409@bria> <13252@lanl.gov> <1652@hpwala.wal.hp.com>
Reply-To: fetter@cos.UUCP (Bob Fetter)
Organization: Corporation for Open Systems, McLean, VA
Lines: 55

In article <1652@hpwala.wal.hp.com> lupienj@hpwadac.UUCP (John Lupien) writes:
>In article <13252@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>>How about reconnect (you know, my modem drops off in the middle of a job
>>and I want to sign on and reconnect to the job)?  Oh, UNIX automatically
>>kills jobs when connection fails except when the job is 'nohup'ed - but,
>>even then, you can't reconnect: the only thing you can do with a
>>'nohup'ed job from a _different_ terminal session is kill it.
>
>Yes, that is the way I want it. This is a very good thing. I do not want
>Mr. Giles to be able to dial up and reconnect to my process. I'd rather
>have it die (gracefully or otherwise) than risk having someone else gain
>access to my process, which may well be running as me. Since DOS has no
>protection features at all, I can understand why this issue is lost on
>Mr. Giles, who is trying to make ignorance a virtue.

  Well, the issue of reconnection to disconnected processes is still a
good one (IMHO).

  In that there is a (very valid) security concern as to leaving the
process directly tied to the dial-in line, the question comes to mind
as to why a disconnected process (process group) *should* remain tied
to the dial-in line if 'nohup'ed.

  On Multics, it was possible to set a process attribute
"reconnect_ok", which would mark a process as one to be preserved if a
line disconnect occurred.  Now, this preservation would *not* keep the
association of the communication line <--> process, but would mark the
process as 'disconnected', placing it in a suspended state *and
freeing the communication line for other use*.

  If the user logged back on the system within a site-configurable
period of time, then *after* the UserId/Password validation, they
would be told that there were (N) disconnected processes (if there
were any) and be given the option to reconnect, start a new login
process (not affecting the disconnected one(s)), etc.
 BTW - after the site-selected time was reached for a disconnected
process, it would be reaped, freeing up whatever resources was being
used (memory, etc).

  For Unix, I would think that this would require the ability to
reassign what would be the base /dev/tty for a 'disconnected' process
(group) if reconnection was requested.

  This above senario removes the security aspect, as the user must
be re-established (userid/password) *prior* to any reconnection being
allowed.

  Is there anything like this in the Unix world today?  I would guess
that there would be a need to collectively tie together all processes
which were children of the initial login 'process' and treat them as a
'group', so that reassociation of them as a unit to a new /dev/tty
could be accomplished.  Or is this something currently deemed "not a
good thing" by the community?

  -Bob-