Date: Sun, 18 Mar 2001 12:31:55 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, stable@FreeBSD.ORG Subject: Re: Not only ftpd's problem with ls */../*..... Message-ID: <200103182031.f2IKVt201726@earth.backplane.com> References: <200103181611.f2IGBf894065@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ultimately the only thing I care about is that we not arbitrarily limit
a global libc function by default, so I don't care which solution is
adopted (api call, structural flag/field, resource limit) as long as
the default for glob() is left unlimited.
There are advantages and disadvantages to using the datasize resource
limit or an API call / structural field inside ftpd to limit the glob
function. The biggest advantage of the datasize resource limit is that
it is under the ultimate control of the sysad and requires no changes
to the system at all (other then backing out the glob commit). The
disadvantage is that our current installworld process will not update
inetd.conf autoamtically, so most of our target audience won't get the
fix.
The advantage of an API call / structure field is that we can build a
reasonable limit into ftpd (and only ftpd), so our target audience gets
the fix as the default, but now we have to provide an additional option
to ftpd to set (or entirely remove) the limit to give sysads the ability
to adjust it.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103182031.f2IKVt201726>