Date: Fri, 25 Apr 1997 09:54:38 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: davidn@unique.usn.blaze.net.au (David Nugent) Cc: msmith@atrad.adelaide.edu.au, 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 ? Message-ID: <199704251654.JAA03574@phaeton.artisoft.com> In-Reply-To: <199704250344.NAA17710@unique.usn.blaze.net.au> from "David Nugent" at Apr 25, 97 01:44:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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. Maybe. Maybe not. It will, as a side effect: 1) Fix the security barrier in the way of writing an SMB client file system (MS LanMan & AT&T StarNet). 2) Fix the security barrier in the way of writing an NCP client file system (NetWare). 3) Fix the security barrier in the way of writing a shared credential system using LDAP. 4) Fix the "can't boot without a local credential file, can't use a distributed credential file until after you boot" chicken-and-egg problem (UnixWare had this problem). 5) Provide a general mechanism for the kernel to request credential (and possibly other) information from the user (either as a cache or by poppong up a console or X requestor). 6) Allow us to finally support file and directory level password authentication requests to the user from the kernel so we can get to work on real object level security, ala Orange Book. 7) Allow the use of PAM (your use, I assume) for retinal scanners, face recognition systems, smart cards, and the more mundane RADIUS stuff (probably your target 8-)). So the side benefits to allowing you to hook this, and then doing the implementation at this particular level, are tremendous. > 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. Ugh. Shades of Deanna Troi saying "Oh, the pain! ...the pain!". Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704251654.JAA03574>