From owner-freebsd-hackers Thu Apr 24 20:45:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA21231 for hackers-outgoing; Thu, 24 Apr 1997 20:45:36 -0700 (PDT) Received: from unique.usn.blaze.net.au (unique.usn.blaze.net.au [203.17.53.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA21210 for ; Thu, 24 Apr 1997 20:45:23 -0700 (PDT) Received: from unique.usn.blaze.net.au (local [127.0.0.1]) by unique.usn.blaze.net.au (8.8.5/8.8.5) with ESMTP id NAA17710; Fri, 25 Apr 1997 13:44:02 +1000 (EST) Message-Id: <199704250344.NAA17710@unique.usn.blaze.net.au> To: Michael Smith Cc: terry@lambert.org, abelits@phobos.illtel.denver.co.us, adrian@staff.psinet.net.au, freebsd-hackers@freebsd.org Subject: Re: Best way to hook into user logins / logouts ? In-reply-to: Your message of "Fri, 25 Apr 1997 12:45:17 +0930." <199704250315.MAA00164@genesis.atrad.adelaide.edu.au> Date: Fri, 25 Apr 1997 13:44:02 +1000 From: David Nugent Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> For "correct" code, given the currently accepted >> implementation methods, the "in" door is "login" >> and/or "login -f". > > xdm does not appear to use login. Yes, more's the pity. This makes life a bitch sometimes. :-) Actually, I have to look at xdm shortly. Aparently David did some basic login class support, but the 3.2 for -current release appears to be missing a few things, if it is done at all. >> Why do you need an "out" door? > >Accounting. Consider a provider wanting to bill for time >spent online by a user. Yes. Or in an educational environment, students have access to equipment for n hours or whatever. Process accounting has no relevence, but real time use of the equipment does. >> my recommendation is "login" forks instead of execs, and >> hangs around as the session manager, but not the process >> group leader. This requires Was that the sound of shattering glass? :-) I know that this will horribly break things in several places. Changing this assumption would require considerable work, and not only to FreeBSD's internal code. I'm not sure that the result would be worth the effort unless no other viable option could be found. >Yeah, although that makes stuff fairly messy. Right now, >the utmp modifications happen in (mostly) the right places >(except for xdm), so I'll probably be following those. They work just fine. What's missing are any dynamic hooks with which an admin can plug in "after user" actions. In -current, at least, there is in fact a "at login" action via the shell= login.conf parameter, but of course this really only applies to interactive logins and not xdm nor pppd style logins. So right now the only viable way is to watch wtmp/utmp. This sucks from the pov that some polling is involved, but even that could be mostly solved when/if poll() is implemented and when/if it would be possible to block on mtime change on a file descriptor. Regards, David