On Tue, 9 Sep 2008, Daan Vreeken wrote:
Which is to say, they don't include the UID -- and I have several hundred
sites, each with its own UID.
Yes, I could go ahead and set up a thousand "deny" rules, one for each
UID -- but being able to log this info (since it IS being checked) would
be great.
It should be possible to add a couple more arguments to ipfw_log() so that
ipfw_chk() can pass it the ugid_lookup flag and a pointer to the
fw_ugid_cache struct. Then you can edit ipfw_log to print the contents of
that struct if ugid_lookup==1. That would result in the logging of uid
for any failed packet that had to go through a uid check on the way to the
deny rule.
Okay, so if it's fairly easy to do, the question would be "since I don't
feel right hacking in this change myself -- how could I propose this as a
feature?" It's not a BUG per-se, but I think it could be useful to others
as well.
I own a webhosting company and here too every domain gets it's own user, so
I like this proposal. I've hacked together a first try, which seems to be
working. A patch (against -HEAD) can be found here :
http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09.diff
Improvements / tips / comments are welcome ;-)
A few observations generally about the use of connection credential data in
the firewall:
(1) UID lookups on connections from the firewall are inherently race-prone and
unreliable; the stack layering violation means that locks may be acquired
independently for the connection lookup at the firewall and socket layers.
This non-atomicity may be fairly acceptable in the event that there aren't
significant delays in processing, but if you also have DUMMYNET pipes in
use then these races may mean significant gaps in time between when a
socket is looked up for check vs. use.
(2) The performance hit of connection lookups in order to find credentials for
received packets may (should) be massive: the input path will look up the
connection for each packet multiple times, acquiring contended locks, etc.
(3) It's currently not possible to look up the connection associated with
several sorts of packets, including ICMP (such as used with PMTU).
Note that all of these problems apply to existing uid/gid/jail credential
rules, which are considered unreliable and non-performant for the same
reasons.
Looking at your patch specifically, it seems you don't force the lookup of
credential information if it hasn't already being looked up for a credential
rule. This should mean that the known problems of (1), (2), and (3) shouldn't
be worse than they were before.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
