Bug#32263: Splitting CGI-BIN
> > > Perhaps things have changed in the last 3 years, and they
> > > shall understand that post the /usr/doc issue policy has become more
> > > conservative?
> > I'm afraid I don't understand what you mean here.
>
> He means the best way to get something in policy is for it to be
> implemented. Of course, the best way to get many things implemented is
> for them to be in policy, first, but hey, when have paradoxes stopped
> us before?
True, but since I'm not the one implementing it, the best I can do is
take the route of changing policy first. I think this is the best method
is this case, though, since the change will affect numerous webserver
packages.
> > No, I mean that <webroot>/cgi-lib should point to /usr/lib/cgi-bin
> > and <webroot>/cgi-bin should point to ~www-data/cgi-bin. The latter is
> > what webmaster expect or, at the very least, they expect to be able to
> > control <webroot>/cgi-bin.
>
> Well, they can do that now -- all they have to do is change the cgi-bin
> override in apache.conf.
They can. I've done this myself. But then none of the Debian packages
that rely upon <webroot>/cgi-bin will work. The purpose of the change
isn't to alter the webserver packages, but rather the packages that make
use of them so they will not conflict with what the webmasters want to do.
> The above would also seem like it would break people's websites and
> bookmarks, a bit, which would seem undesirable.
>
> What would y'all think about having cgi-bin managed more like, umm:
>
> /usr/lib/cgi-bin/
> <packages dump CGI scripts in here willy-nilly>
> ~wwwdata/cgi-bin/
> <packages make symlinks to /usr/lib/cgi-bin/blah in postinst,
> based on some setting in /etc/ somewhere>
This has how I've done my site, but it's a pain. Also, many webmasters
run virtual websites and thus such symlinks would have to be done (or not
done) for each webspace and that's not something can be easily automated.
> > I believe that <webroot>/cgi-bin should access local cgi-scripts since that
> > is the traditional method and the way most webmasters layout their site.
> > I'd like to use <webroot>/cgi-lib for access to the system cgi-scripts.
>
> Hrm. Does it really make sense to have to change all your "cgi-bin/blah"
> references to "cgi-lib/blah", just because you choose to use a packaged
> version of the cgi script, or vice-versa?
That's up to the webmaster. If they are using Debian packages from within
their own pages, they can create a symlink exactly as you describe above.
However, not creating the symlink won't affect those pages completely
controled by other packages, like dwww. By splitting thing, the webmasters
have the choice.
> (I'm somewhat interested in fixing the "unwanted services becoming
> available, and possibly posing a remote security risk just 'cause I
> installed some package to look at some files" problem, which I think
> the above suggestion might do)
That's an excellent point. A webmaster could change <webroot>/cgi-lib
to point to ~www-data/cgi-lib and then only create symlinks for those
scripts he wants enabled for that (virtual?) host. For the most part,
though, people that install a web-based package want it to be available
so I think that is a good default.
> I'm assuming, of course, that webservers can cope with symlinks to CGI
> scripts in their default cgi-bin directory...
They can. Apache needs a "FollowSymlinks" option enabled.
Brian
( bcwhite@precidia.com )
-------------------------------------------------------------------------------
If you love something, set it free. If it comes back, it was, and always
will be yours. If it never returns, it was never yours to begin with.
Reply to: