From owner-freebsd-hackers Mon Jan 6 14:21:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA04600 for hackers-outgoing; Mon, 6 Jan 1997 14:21:39 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA04589 for ; Mon, 6 Jan 1997 14:21:35 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA12748; Mon, 6 Jan 1997 15:11:56 -0700 From: Terry Lambert Message-Id: <199701062211.PAA12748@phaeton.artisoft.com> Subject: Re: file locking / firewalling based on uid/gid To: dennis@etinc.com (dennis) Date: Mon, 6 Jan 1997 15:11:56 -0700 (MST) Cc: avalon@coombs.anu.edu.au, hackers@freebsd.org In-Reply-To: <3.0.32.19970105125150.00687428@etinc.com> from "dennis" at Jan 5, 97 12:51:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >(To me, filtering based on UID implies you're doing things at a higher > > level than normal packet filtering and should be a separate beast rather > > than coming up with kludges to extend ipfw. Heck, there are many more > > and different checks you can make, for a start...). > > I agree. It seems that firewalling and "authentication" are getting > entwined... > which is not a "bad" thing as long as there is no penalty to pay by one or > the other. We've recently combined our bandwidth management, queue > prioritization and filtering functons, but made it a single-pass function to > eliminate the performance penalty. We must seperate credential instances from process group instances and attach them to session instances instead. Each credential for a given machine can have only a single session instance, with a potential of N process group instances sharing a pointer to the session instance. A setuid/setgid operation would establish a new session instance (if a session for the new credential were not present on the system) and decrement the reference count for the previous credential. When the reference count gose to 0, the session is destroyed. We need session instanced to implement "password caches" for non-BSD originated credentials associated with an identity instanced by a session. For instance, for use in NetWare or SMB file systems. We have the potential for "auto" session management, with a session manager registration mechanism for a given process group, to allow for credential query by the kernel if a mechanism for a covert channel to the user exists (ie: ask for the user's SMB password using an X-based dialog for a process group running under XDM, etc.). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.