[pf4freebsd] Re: Comments? FreeBSD-only change (group -> groupmember)

[Pyun YongHyeon]

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>