mark@hcrvax.UUCP (Mark Ashworth) (04/26/84)
[]
Does anyone know about or have a facility implemented on Unix Version 7
or System V to Auto-logoff users in the system who have been idle for a
period of time? Suggestions on how to implement such a facility would
be very welcome also.
Please send mail to: {utzoo,utcsrgv,decvax,cbosgd,ihnp4}!hcr!hcrvax!mark
Thank-you in advance
Mark Ashworthebk@iedl02.UUCP (04/29/84)
> Does anyone know about or have a facility implemented on Unix Version 7 > or System V to Auto-logoff users in the system who have been idle for a > period of time? Suggestions on how to implement such a facility would > be very welcome also. A number of auto-logoff mechanisms were written at ODU as undergraduate projects. The most common mechanism was to check the difference between the accessed and modified dates of the tty file. This has the unfortunate effect of killing anyone running a long computation. One version peeked around in the kernel data and watched the accumulated runtime or some such nonsense. This is similar to trying to do something whenever anyone logs off - UNIX wasn't set up for administrative overseeing like this. The best, and certainly safest way of doing this is to add a couple lines to the shell(s). Before the read for the command line, say alarm(MAXIDLETIME); You might want to catch SIGALRM and print a message or something. This has the advantage that you never kill anyone who is computing without using the terminal, but is easy to get around - just type `ed'. Any check on tty use (kill the process if its wchan is a tty and it's been idle for x seconds) is just as easy to get around: `sleep 3600'. If you try and get too clever, someone is going to resort to: main() {for(;;);} and kill your load average. I was going to digress on how non-UNIX-like this type of thing was, but I suppose that there are times where this is necessary (overcrowded terminal room at a university, for instance.) Just be sure that you and your users know exactly why you are doing it. Chances are you have at least one hacker-type there who will figure out how to get around it, and if it's perceived as "administrative oppression", pretty soon everyone will know except you. A practical guideline: only run it during whatever hours and days are "prime time" for you, and don't exempt anyone except the operator, if you have one. ------------------------------------------------------------------------ John Owens (804) 978-5826 ...!decvax!mcnc!uvacs!icase!oducs1!owens_j
jerry@oliveb.UUCP (Jerry Aguirre) (04/30/84)
The people responding the request for an auto-logout facility seem to
see it as an attempt to reduce load to the system or make terminals
available. I see it as a security issue. It is not uncommon for
users to leave their terminals logged on for the entire weekend.
Any one with physical access to their terminal can override their
security. Just ask yourself if there is anyone who is mean or
stupid enough to do a rm -rf ~/. on your terminal. All the recent
discussion about the password algorithm and picking difficult
passwords is worthless if the penetrator can just wait for someone
to go to lunch and then use his terminal.
And before someone complains about the user getting what he deserves,
remember that it is the Unix support group who has to restore his
files! The user gets the morning off and a good excuse for having his
project late. Unix gets a reputation for loosing files or having poor
security.
I have heard from several sources this idea of idle users loading
the system. As I understand it the user is tying up a process slot
and some swap space. If the user wasn't using the process slot
there would be a getty running in it. It seems to me that the
overhead for logging out and back in is greater than any savings.
Is this idle user loading bunk or is there a legitimate reason
(besides security) for logging off between sessions?
Jerry Aguirre
{hplabs|fortune|ios|tolerant|allegra|tymix}!oliveb!jerrydarrelj@sdcrdcf.UUCP (04/30/84)
We had autologoff here for a while. The primary reason was that we have
many more users than terminal lines (typically we could keep about 30 of 32
lines busy) so people would stay logged in to avoid being stuck in a queue
to get another line later. This line hogging only exacerbated the problem
(which could be seen by how early all 32 lines got grabbed). It proved to
be politically unpopular to have autologoff (the situation was still worse
for a while as some of the security holes in unix let knowledgeable users
manually zap idle terminals to free the line; stty 0 still results in a
message identifying the user which is hanging up the line). The effective
solution here was to add 8 more tty lines, virtually guaranteeing a line
will be free at all times (and actually resulted in FEWER lines in use most
of the time -- no longer need to hog a line).
--
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,sdccsu3,trw-unix}!sdcrdcf!darrelj
VANBUER@USC-ECL.ARPAgwyn@brl-vgr.ARPA (Doug Gwyn ) (05/02/84)
Our version of the Bourne shell will timeout the user if he doesn't respond to a PS1 prompt within a specified amount of time. The environment variable TIMEOUT contains the allowed time in minutes. Obviously this is not user-proof and in fact setting TIMEOUT=0 will disable the feature. The intention is to terminate the shell on an "abandoned" terminal, like when a fellow goes home for the day and forgot to log out first.
ado@elsie.UUCP (05/02/84)
Our version of the Bourne shell will timeout the user if he (sic) doesn't respond to a PS1 prompt within a specified amount of time. The environment variable TIMEOUT contains the allowed time in minutes. Obviously this is not user-proof and in fact setting TIMEOUT=0 will disable the feature. The intention is to terminate the shell on an "abandoned" terminal, like when a fellow (sic) goes home for the day and forgot to log out first. Would requiring users to type in their passwords (rather than logging them out) be preferable in a set-up like this? -- UNIX is an AT&T Bell Laboratories trademark. -- UUCP: decvax!harpo!seismo!rlgvax!cvl!elsie!ado DDD: (301) 496-5688
gwyn@brl-vgr.ARPA (Doug Gwyn ) (05/03/84)
No, asking for password again rather than logging out is not suitable for our environment (OS ports are a scarce commodity and we have to free up an idle line so the queued-up users can get through the port contention switch). I also don't think the shell has any business asking for your password.
ado@elsie.UUCP (05/04/84)
brl-vgr!gwyn-- > Our version of the Bourne shell will timeout the user if he (sic) > doesn't respond to a PS1 prompt within a specified amount of time. . . > The intention is to terminate the shell on an "abandoned" terminal, like> when a fellow (sic) goes home for the day and forgot to log out first. elsie!ado-- > Would requiring users to type in their passwords (rather than logging > them out) be preferable in a set-up like this? brl-vgr!gwyn-- > No, asking for password again rather than logging out is not suitable > for our environment (OS ports are a scarce commodity and we have to > freeup an idle line so the queued-up users can get through the port > contention switch). I also don't think the shell has any business > asking for your password. Thanks to gwyn for the added information about the purpose of the TIMEOUT stuff. A question: how is it that we decide that logging off users after a time IS the shell's business while asking for your password is not? -- decvax!harpo!seismo!rlgvax!cvl!elsie!ado (301) 496-5688
mckeon@unm-cvax.UUCP (05/05/84)
[chomp] A version of C shell we had before 4.2 allowed set autologout=N # N equals max idle time in minutes Unfortunately 4.2's C shell doesn't have this, and I don't recall if we got the version that did off one of the 4.1 tapes, or somewhere else. In an environment of heavy contention for processor ports and dial-in lines; and of people who don't mind being logged out (who would rather log in again than build large idle times & take up a port) 'autologout' is a winner, but in a less contentious environment it can be a pain. Don't recall how to disable it once set, but probably by setting the time to 0. The suggestion regarding password prompting sounds like an automagic invocation of 'lock' - does protect the user, but still consumes the port. These seem to be separate issues.
arnold@gatech.UUCP (Arnold Robbins) (05/08/84)
[This Space For Rent]
This would really only work on USG Unix, but if you have the TIMEOUT
facility in your /bin/sh, and you (i.e. the system administrator) want to
force auto-logout, it is pretty easy. Just add two lines to /etc/profile:
TIMEOUT=... # set to amount of time
readonly TIMEOUT
The USG sh, when it is a login shell, reads /etc/profile, and then .profile
in the home directory. Making TIMEOUT readonly will 1) keep users from
changing it, and 2) automatically export it to subshells.
Of course the knowledgeable/devious user can always get around it:
while : # : exits w/value 0, or true
do
sleep 300 # sleep 5 minutes
done
which keeps the port tied up, the shell busy, and doesn't use a whole
lot of cpu time. Nothing's perfect.
--
Arnold Robbins
CSNET: arnold@gatech
ARPA: arnold%gatech.csnet@csnet-relay.arpa
UUCP: ...!{akgua, allegra, rlgvax, sb1, ut-sally}!gatech!arnold
"All this digital stuff is just a fad. Analog is the way to go."
-- William M. Robbins, 1984guy@rlgvax.UUCP (05/11/84)
> This would really only work on USG Unix, but if you have the TIMEOUT > facility in your /bin/sh, and you (i.e. the system administrator) want to > force auto-logout, it is pretty easy. Just add two lines to /etc/profile: > TIMEOUT=... # set to amount of time > readonly TIMEOUT > The USG sh, when it is a login shell, reads /etc/profile, and then .profile > in the home directory. Making TIMEOUT readonly will 1) keep users from > changing it, and 2) automatically export it to subshells. > Of course the knowledgeable/devious user can always get around it: The knowledgable/devious user can always say exec /bin/sh which voids all "readonly" "declarations". So much for "readonly" as a security measure, except in restricted shells... Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
gwyn@brl-vgr.ARPA (Doug Gwyn ) (05/12/84)
sh TIMEOUT was already present when I arrived at BRL, so I am not sure of all the reasons for doing it this way. One major factor I am sure of is that the shell has the information it needs to decide that the user has fallen asleep (lack of response to PS1), whereas any other approach to logging off an idle terminal would seem to involve peeking inside the kernel or running "ps" periodically to see whether anything had been accomplished by the user's processes recently. Doing this in the shell seems cleaner. Note that this is not intended to be an absolute guarantee that an idle terminal will be forced to log off, and we even let the user choose the timeout interval or turn off the feature altogether. The sh TIMEOUT is not foolproof, since &-detached processes are not checked and may therefore get sent a SIGHUP when the shell times out. This could obviously be fixed, but it seems to be a rare problem given that the default timeout interval is 30 minutes and that we have a BATCH facility (part of the MDQS spooling system, works really well).
jab@uokvax.UUCP (05/21/84)
#R:hcrvax:-37900:uokvax:6200026:000:414 uokvax!jab May 20 20:50:00 1984 /***** uokvax:net.unix-wizar / altdal!tudor / 9:00 am May 17, 1984 */ : : /etc/idleoff : W. Tudor ApMadoc : April 17, 1983 : execute via entry in /usr/lib/crontab every 30 | 60 minutes /* ---------- */ At least this person was polite enough to send a SIGTERM to the processes before it sent them back to God. (Take note!) The twerps on the machine I normally run on aren't so kind. Jeff Bowles Lisle, IL