Date: Thu, 16 Sep 2004 04:09:15 -0000 From: Pyun YongHyeon <yongari@kt-is.co.kr> To: pf4freebsd@freelists.org Subject: [pf4freebsd] Re: Comments? FreeBSD-only change (group -> groupmember) Message-ID: <20040721075003.GA11450@kt-is.co.kr> In-Reply-To: <200407210045.06274.max@love2party.net> References: <200407210045.06274.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 21, 2004 at 12:44:58AM +0200, Max Laier wrote: > > during a discussion about ipfw's user/group filter capabilities and it's > implementation with Christian S.J. Peron we found that pf only applies group > filter based on the primary (effective) group of the user, rather than taking > all member groups into account. This is a major backdraw for multiuser > environments, where you want to allow/deny a large group of people certain > network access, say: > pass out on $dmz from $dmz to $cvsserver port 22 group cvsuser keep state > I don't have strong negative view. Personally I don't use uid/gid matching rule, atm. I don't like to perform excessive PCB lookups in order to filter packets depending on socket credentails. When a program is run by a user there is only one instance of *effective* uid/gid pair at a given time. This enables pf/ipfw inspect socket credentails at the time of packet verification. It seems that current implementation makes use of a kind of cache to accelerate the lookup process. Considering uid/gid can be modified at any time during program's life span and assuming kernel is fully re-enterent, there is a possibility of stale uig/gid credentail reference due to the cached data. Of course, depending on running environments, this might be acceptable. Basically, I believe uid/gid matching is layering violation (inspectation of socket data in L3) and is fragile enough if we add more complex routines there(cache maintenance, locking etc). For really busy-server(I guess it's common for pf based firewall/ server.), there would be many users/groups and the system would have thounds of sockets opened and have pushed the network into wire-speed. In that situation, considering just one uid/gid cache bucket, how effective the cache is? Regards, Pyun YongHyeon -- Pyun YongHyeon <http://www.kr.freebsd.org/~yongari>;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040721075003.GA11450>