fetch extension - use local filename from content-disposition
header
Martin Cracauer
cracauer at cons.org
Thu Dec 29 19:15:08 PST 2005
Matt Emmerton wrote on Thu, Dec 29, 2005 at 10:09:03PM -0500:
> > Sean Bryant wrote:
> > > Barney Wolff wrote:
> > >
> > >> On Thu, Dec 29, 2005 at 07:33:38PM -0500, Martin Cracauer wrote:
> > >>
> > >>
> > >>> I'm a bit rusty, so please point me to style mistakes in the appended
> > >>> diff.
> > >>> The following diff implements a "-O" option to fetch(1), which, when
> > >>> set, will make fetch use a local filename supplied by the server in a
> > >>> Content-Disposition header.
> > >>>
> > >>
> > >> Have you considered the security implications of this option?
> > >>
> > >>
> > >>
> > > Its just an extra option. I'm sure the details could be summed up in the
> > > man page.
> >
> > I think what Barney means is that if you run fetch(1) as root and the
> > server returns the filename as "/sbin/init" bad things will happen.
> > The data returned in Content-Disposition should be used with caution.
>
> Would checking to see if the target file exists, and if so, abort the
> operation and display a warning be sufficient to address the security
> issues? Of course, we'd need some kind of "force" option to override this
> for the foot-shooting folks, and -f is already taken, but that could easily
> be documented as a "limitation" of this option.
I don't like it since it derives too much from standard behavior which
is to use a local name derived from the URL, even if it exists.
Also, not overwriting files doesn't cut it for security, you could
e.g. create a nonexisting .rhosts or .ssh/authorized_keys or play
similar games.
Forbidding "/" will set the security to the same level as the base
functionality. I like that.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer at cons.org> http://www.cons.org/cracauer/
FreeBSD - where you want to go, today. http://www.freebsd.org/
More information about the freebsd-current
mailing list