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>