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.