sean finney wrote: > - that cgi-bin is defined to be a location outside of debian packages' > reach entirely (/srv/www/cgi-bin or /var/www/cgi-bin, or whatever). > - httpds which support scriptaliasing ship this as the default location > - httpds which can not scriptalias it somewhere else (those that hard-code > it at compile time, i'm guessing > 0 may do this) use that as the location. > - applications which wish to provide cgi-bin based scripts are allowed > to use the scriptalias function of applicable httpds to claim > subdirectories of cgi-bin. > - under no circumstances are packages to place files in the default > cgi-bin location. > - it is the admin's privilege/responsibility/authority to modify the > contents of the default cgi-bin location.
AFAIK apache2 is the only web server package that allows scriptaliases to be added to it in a policy conformant way (by dropping config file snippets into /etc/apache2/conf.d/. Other web servers that support scriptalias, like boa, centralise it all in a single conffile, which other packages are not allowed to edit. That's why I said that there being more web servers than apache2 in Debian is a problem. > with this approach, the admin is free to do whatever he/she wishes with > the cgi-bin directory (place files, symlink to directories provided > by debian packages, etc), without interference from debian packages. > there is also a clear distinction of domain between the local admin > and the debian package management system, which is generally a good > thing and something we seem to like doing in debian. Of course using /cgi-lib/ for debian's cgis and /cgi-bin/ for the admin also draws a similarly clear distinction, although the naming of /cgi-lib/ could be clearer (as was mentioned in the policy proposal). -- see shy jo
signature.asc
Description: Digital signature
