On Thu, Mar 07, 2002 at 11:03:19PM -0500, Robert Watson wrote:
> A couple of comments:
>
> - You can always cache the pcb the first time it's used, and then have it
> available for future use. I agree with your concerns about generating
> it every time -- that would be a disaster for routers where no packets
> are even delivered locally. :-)
you can't cache it and make it available for future use without making
the invasive changes that i mention:
> > first, having a uid or gid rule in your ipfw ruleset (or even running
> > ipfw) certainly isn't the common case. we're now going to bloat the
> > ip_fw_chk() calls protocol handler calls to add an arguement that 99%
^-- "and"
> > of time is going to be NULL. then you have to bloat the protocol handlers
> > to check if that pointer, that is NULL 99% of the time, isn't NULL.
i think that ip_fw_chk() taking _8_ arguments is getting a bit obscene.
adding another one to the protocol handlers doesn't seem like a great
idea either.
we're talking about an optimization that less then .1% of our userbase
will ever take advantage of v. a pessimization (additional argument in
the protocol handler + check of that arguement in the handler) in the
critical path of packet delivery in ALL cases (even kernels w/o ipfw).
it's just not worth it.
with ipfw cacheing the pcb lookup + credential check and w/o terry's
patch, the worst case would be a ruleset with any uid/gid rules: a pcb
lookup being done twice (once ever in ipfw, once in the protocol handler).
that's really not so bad compared with the current behavior with uid/gid
rules where the lookup is done of a lot of times (as many uid/gid rules
you walk through before you match) in ipfw and once in the protocol
handler.
> - The uid/gid code is broken for a number of important applications,
> including SSH forwarding, because SSHd binds the socket using a root
> credential rather than the user credential. Arguably, this is a bug
> with SSHd, and it also breaks a number of other things including the MAC
> support we're adding to 5.0-CURRENT. Also, it had some *evil* bugs
> involving NFS that I recently fixed in 5.0-CURRENT, where sockets were
> rebound using the credential of the user making the VFS operation,
> resulting in ipfw uid/gid rules dropping/rate-limiting file system
> requests for all users. For those running into the whole sshd tunnel
> and ident problem, it's the same cause.
i would like to make my cache have the proper credential(s) rather then
just cache the current socket credentials cr_uid, if that's wrong.
please let me know privately just what exactly i should be comparing
against (or functions i should be using, if an API exists now) in -current
with the changes to credentials.
when i mfc the cache, i'll just keep the current uid comparing behavior.
--
- bill fumerola / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
- my anger management counselor can beat up your self-affirmation therapist
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
