Hi,
I notice in my Sun Solaris 8 sparc workstatin, I am able to login concurrently using a same user ID.
Is there a way to disallow this? That is, at anyone time, the user can have only 1 login session.
How can it be done?
Thanks
You would have to write a script that looks for that user account already on the system (insure you still allow root, administrators, possibly DBAs, oracle, sybase...to still have multiple logins).
Put the code or a call to the script into /etc/profile. Note, rsh and rlogin would still be able to get around this.
For other ideas, try this Info on Netsys.com
You could write a simple line in the login script that looks for a lock file, something like /etc/logins/lock_your_user_id and then if it does not exist, allow the login and then create the file. This is a simple file locking mechanism that is used a lot in UNIX systems and could be used here very easily.
this seems to be a good idea. but when will the lock file be deleted? what if user just does not logout but plug out the electric power cable?
Hi,
you can try a different variant of the same concept. Check for the particular user's session count as part of the startup script and decide on allow him or not...
Thanks...
Naturally, you would have to clear the lock files when the system reboots after a crash. This is true for all programs that use lockfiles. You simply write a startup script that looks for and clears lock files when the system reboots.
As for logout actions, this is possible also. One possibility is to use the trap facility in the shell.
Hi,
If the user pulls the power cable of server, lock files can be cleaned while startup..
How to clear the lock files, if the user pulls the power cable of the terminal ?. ( client )
Thanks in advance...
Ok, good question...
Well there are two possibilities here....
Maybe "pulling the plug" will drop dtr on a terminal or something that will result in the shell getting a HUP signal. In this case, the shell will exit and it will perform the .logout or the trap commands that will remove the lock file. The user, at this point is no longer "logged in", the lock file is gone and there is no problem.
Or maybe "pulling the plug" will not result in a HUP being sent to the login shell. So it will continue to sit there. The user is still "logged in", the lock file continues to exist. And so the user cannot login again.
That is the whole point, right? No concurrent logins? If this bothers you, then why do it?
Users should not be "pulling the plug" as a logout mechanism. I would pose the same question to them: It this bothers you, then why do it?
There are some counter-measures that can help some here. Most shells have a timeout mechanism. For example, in ksh you can set TMOUT to a number of seconds. When that number of seconds passes without a command being typed, the shell will exit. As it does, it will execute any commands set to "trap" on signal zero. A built-in shell timeout mechanism will work for any style of connection. And the user can customize the timeout period to suit his needs.
If they connected on a directly attached terminal, they can turn it back on and continue with the session. You should be able to arrange for the port to notice DTR from the terminal dropping when a terminal is turned off. This would send a HUP to the login shell.
If they are connecting via modem, you have a real security problem. You need to insure that when the modem notices that carrier dropped, a HUP is sent to the login shell. If this is not done, the next person to use that modem will inherit the first persons session.
If they are connecting via tcp/ip, you can configure keepalives to break the connection and send the shell a HUP in the process. But whatever you do will affect all tcp connections. Tcp keepalives are controversial so you may want to think about this first.
No matter what you do, you are going to have folks who do not logout correctly and may leave a session out there.
If you use something like introcomp.co.uk - restrict login you would also have to have something to kill off users who are idle for a certain amount of time. Setting up each .profile would also be a hassle (especially if with the linked script ) if you wanted to change how many logins were allowed. Setting up a link from all home directories to a common .profile might be a way around that ( it matters if your home directories are NFS mounts or not).
Found that this works just as well in /etc/profile - of course, you might want to change the logic and allow root and other special accounts to get around the limit set.
Also note that the script does not stop Control-C break outs which could allow folks to have more than one session. A cron script to look for specific user and more than one terminal association could kill off second process (again, more work to figure out which is which).
Without 3rd party software which would make this easier, your options are limited and a headache you might not want to do.
If someone pulls the power cable, you simply clear all lock files during the reboot process. There are no sessions after a power failure so it is appropriate to clear all the session locks.