Chad David <[EMAIL PROTECTED]> wrote:
> I was just wondering about the caveat in that access(2) man page
> that says that access is a potential security hole and should
> never be used, and the fact that ipfw calls it on line 2435.
>
> I seem to recall a discussion about this a few months ago, but
> I don't really remember the details... and the irony of ipfw
> calling a documented "should never be used" function got my
> attention.
>
> Is this really a problem, or is the man page paranoid?
The manual page is probably paranoid, but I don't think we should
change it. It's very easy to abuse access(2). It's a potential
security hole if you use it to provide access control. E.g., you're a
setuid process, and you got a filename as an argument. You want to
open it, but only if the user that called you has sufficient
privileges to do so. Using access(2) on that filename and opening it
if it returns success would be a security hole, because that file
might've changed (mv, cp, chmod, whatever) between your call to
access(2) and your call to open(2) (classic example of a race
condition). The right thing to do would be to drop effective
privileges to that of the user, and use open(2) directly.
ipfw just wants to know if its last argument is a valid filename (see
the first usage form in the manual page). I think that's a pretty
legitimate use, although it shouldn't rely on the fact that the file
will exist and/or be readable when it gets around to opening it.
I.e., it should still handle a failed open gracefully--and it does.
One can still trick it into trying to open a file that isn't there,
but the results won't be any more spectacular than doing that to any
other program (e.g., `cat /nonexistent`). Besides, ipfw isn't
privileged.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
