lundsga@stolaf.UUCP (Soren K. Lundsgaard) (05/08/84)
Re: article <895@elsie.UUCP>, Re: Auto-logoff facility in Unix 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? Thats a dumb question, and one that I run into a lot. My answer: Make the decision. My reasons and rationale: If you have the power to make the decision, who cares what rationales you use. People are always worried about ruining the Unix environment by changing it. But they don't understand that that is why Unix is such a good environment. Here at St. Olaf we have hacked Unix to bits, adding whatever we want to the kernel. Now, it is still Unix, we can still run version 7 binaries on our 11/70, and 4.1 binaries on our 780, but our operating system and user environment are tailored to our needs. I think that that is what has consistenly made Unix so popular. Could it be true that once people start running little boxes with a binary Unix, they will be dissatisfied with it? sure. I can see leaving here, and hating the new environment. Why, because our environment is tailored to our needs, (and it has some nifty mods too. For example, we don't use the command 'ps' here, and have a much better way to find what processes are running etc.) Sorry for diverging, but my point is twofold. 1) Why go to the net and ask people why or why not you should do something. Do it. 2) Unix was meant to be tailored to individual needs. Don't feel bound to stay within the 'Unix' philosophy. Play an active role and change it. As Lewis Thomas has stated, 'Perfection can only be reached by Change.' (or something like that.) Soren K. Lundsgaard. St. Olaf College. Northfield MN.
wapd@houxj.UUCP (Bill Dietrich) (05/08/84)
The main reasons to ask before going ahead and modifying something are : - there is half a chance that someone has done it already, so you can save the work, perhaps see several different ways of doing it, or connect to an emerging standard. - by being hesitant about modifying something, you are trying to keep it as standard as possible. This is good because - your users don't die when they move in or out of your environment (suddenly the X feature which they used every day is gone, and they have to reinvent or relearn). - your shell scripts don't die when you move them (the converse is true; you would like to snag scripts from the net without having to also snag 5 neat modifications to the shell that the script depends on). - your programs port back and forth (only a problem if people are modifying kernel, libraries, compilers and/or include files, but nothing is sacred any more). - you don't die when updates or new releases are distributed, and suddenly an update is no longer semi-automatic, and a new release makes all of your modifications disappear. - after a little thought and searching for existing features, and consulting people on the net, you may have had time to think further about the modification and realized that it isn't such a good idea after all. If you had jumped right in and made that little twiddle that seemed straightforward, you might have found out the hard way a year later that it had the unintended effect of making a security hole, screwing up all of your backups, or degrading your performance by 5 percent. In general, being overly aggressive is probably worse than being overly cautious. Bill Dietrich houxj!wapd
ado@elsie.UUCP (05/11/84)
elsie!ado-- > 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? stolaf!lundsgra-- > Thats a dumb question, and one that I run into a lot. > My answer: Make the decision. > My reasons and rationale: If you have the power to make the decision, > who cares what rationales you use. > . . .Why go to the net and ask people why or why not you should do > something. Do it. Who cares what rationales you use? I do. If there are good reasons behind a decision that I can apply when making other decisions, I'm ahead of the game. That's why I asked the dumb question--and why I was glad to see brl-vgr!gwyn's answer. Why go to the net and ask people why or why not you should do something? I do it because most of the time a network reader knows more about "something" than I do--and is willing to share the knowledge. -- UNIX is at AT&T Bell Laboratories trademark. -- decvax!harpo!seismo!rlgvax!umcp-cs!elsie!ado (301) 496-5688
dhb@rayssd.UUCP (05/14/84)
Personally, I feel that whenever a choice must be made in how to implement a particular feature, or even which of several possible features to implement, there MUST be a valid rationale. In the particular case of timeouts vs. asking for the password again, there are several things that must be considered. First and foremost is the question of what is the intended purpose of the change? At our site we added timeouts because we have 40 ports on the machine serving a user community of approximately 200. Our main concern was to get people who were just sitting idle at their terminals off the system. If your machine has plenty of ports available but you are concerned about security, then asking for the password might be a valid approach to take. Another thing to consider is how much time do you want to spend making the changes. A fixed time limit on entering a command can be ad- ded to either the Bourne or C shells in as few as three or four lines of code. Password checking is going to require a little more thought. One last thing to consider in this particular case: on reading through the code for the Bourne shell one finds that the timeout feature was in there at one point in time ( con- trolled by an environment variable) but has now been taken out. A closing side note to any other site out there that might be im- plementing timeouts in the shell. As I said above, our main con- cern was getting people off the system. When I made the changes to the two shells to have timeouts, I did it through control of an environment variable. To make sure that no clever users set there timeouts to four days or zero, I added a check to only al- low values between 1 and 15 minutes. Since I didn't want to clutter up the code that sets the variables what I did was check the value just before I wanted to use it and if it wasn't within the proper range, reset it to a default value. By the way, I also allowed 'root' to set the value to zero so that single user mode would not automatically time out after 15 minutes. -- Dave Brierley Raytheon Co.; Portsmouth RI; (401)-847-8000 x4073 ...!decvax!brunix!rayssd!dhb ...!allegra!rayssd!dhb ...!linus!rayssd!dhb