[comp.unix.ultrix] Idle user logoff

bglenden@colobus.cv.nrao.edu (Brian Glendenning) (01/01/91)

I realize this has been hashed to death, but I never thought I needed
to pay attention before (and no, this isn't in the FAQ posting - maybe
it should be?).

I recently got a Decstation 3100 on my desk. It is very strict about
it's 2-user license. Could someone please forward good solutions for
how to logoff "idle" users? Unfortunately it is very easy for people
to do an rlogin and forget about it.

Please reply by email since this has been discussed so often on the
net. Thank you. If you don't know the answer either I will forward
it/them to you when I find out.

Brian
--
       Brian Glendenning - National Radio Astronomy Observatory
bglenden@nrao.edu          bglenden@nrao.bitnet          (804) 296-0286

bglenden@colobus.cv.nrao.edu (Brian Glendenning) (01/04/91)

Thanks for the many helpful replies I have gotten. I have discovered a
bug in untamo. Since I don't know who is responsible for it any more
(mail to doc at purdue bounced) I'll post it here so at least the
people who told me about untamo will see it:

In untamo.c we find the lines:

				pswd = getpwnam(utmpbuf.ut_name);
				user->ugroup = pswd->pw_gid;

but if we look in <utmp.h> we find

struct utmp {
	char	ut_line[8];		/* tty name */
	char	ut_name[8];		/* user id */
	char	ut_host[16];		/* host name, if remote */
	long	ut_time;		/* time on */
};

Thus if your user name is 8 chars, ut_name won't be null terminated
(you'll probably get ut_name and ut_host concatenated before you get a
termination). This will make getpwnam fail and return a null. Then in
the second line you will be dereferencing a null pointer. Bang. core
dump.

The cure is to at least check that pswd isn't null before
dereferencing, and probably to do something like:

		{ char name[9];
                  strncpy(name,utmpbuf.ut_name,8);
		  name[9]=0;
		  ...
		}

And check the return on getpwnam. But I can't see how to make it work
at all for user names longer than 8 chars, although I guess you could
hope that they are unique in the first 8 and look through each entry
of the passwd file.

Brian
--
       Brian Glendenning - National Radio Astronomy Observatory
bglenden@nrao.edu          bglenden@nrao.bitnet          (804) 296-0286

peirce@gumby.cc.wmich.edu (Leonard Peirce) (01/07/91)

In article <BGLENDEN.91Jan3154358@colobus.cv.nrao.edu> bglenden@colobus.cv.nrao.edu (Brian Glendenning) writes:
>
>Thanks for the many helpful replies I have gotten. I have discovered a
>bug in untamo. Since I don't know who is responsible for it any more
>(mail to doc at purdue bounced) I'll post it here so at least the
>people who told me about untamo will see it:

The "keeper" of untamo seems to have disappeared.  I sent them a fix for
the bug you mention plus a few others almost a year ago and haven't heard
anything from them.  Is anyone at Purdue still taking care of it?
--
Leonard Peirce                  Internet:  peirce@gumby.cc.wmich.edu
Western Michigan University                peirce@gw.wmich.edu
Academic Computing Services     UUCP:      ...!uunet!sharkey!wmichgw!peirce
Kalamazoo, MI  49008            Phone:     (616) 387-5469

mathisen@dali.cs.montana.edu (Jaye Mathisen) (01/07/91)

In article <1991Jan7.135259.11464@gumby.cc.wmich.edu> peirce@gumby.cc.wmich.edu (Leonard Peirce) writes:
>
>The "keeper" of untamo seems to have disappeared.  I sent them a fix for
>the bug you mention plus a few others almost a year ago and haven't heard
>anything from them.  Is anyone at Purdue still taking care of it?




If nobody steps forward, I'll be happy to track changes and keep an updated
copy around.   I have some local mods to untamo that I've found useful, perhaps
someday I'll get 'em in some semblance of order...

If you've got patches to untamo, blast 'em to me, and if somebody at purdue
raises a hand, I'll send what I've collected off to them...

Please e-mail them to osyjm@{caesar,}cs.montana.edu.
--
Jaye Mathisen,sysmgr 410 Roberts Hall,Dept. of Computer Science
Montana State University,Bozeman MT 59717         PHONE: (406) 994-{4780,3931} 

sac@decuk.uvo.dec.com (Stephen A Carpenter) (01/10/91)

If you run the tcsh you can set a variable called autologout
to log off idle users.

Stephen.