[development] no .htaccess perms 500 kills drupal.

[Bèr Kessels]

Op donderdag 8 juni 2006 13:58, schreef Morbus Iff:
> > Today I ran into another server that did not allow .htaccess. If it finds
> > one, it dies with a 500 (I beleive this is non standard, but it might be
> > used in more places, I saw it twice). A person asked for my help because
>
> That is not correct. If the server did not allow an .htaccess file, it
> would *ignore* them. In your case, the server *is* allowing an .htaccess
> file of some kind, only the directives that Drupal ships with are
> unallowed for the user, and thus it gives a 500. If you check your
> Apache error log, you'll get the exact reasoning.

Yes. I should have been more precice. Not hte file itself, but something 
inside it broke the server. The server, however, allows *nothing*. So 
virtuallly similar ot "when a .htaccess exists a 500 occurs".

> However, you may be running up against:
>
>   http://drupal.org/node/67244

Indeed. I will follow up there.


> > We should not make .htaccess files from with Drupal, not on upgrades
> > and not after installation. Or at least not in this particular situation.
> > It locks people out, without a hint whats happening
>
> Again, not entirely accurate. The only .htaccess we create in Drupal is
> in the user's configured "files" directory. The only time the 500 error
> would occur is if someone *directly* accessed a URL under the files/
> directory. If you're seeing otherwise, then you've got a really weird
> server, and we can't cater to it without negatively impacting commons.

Rather accurate. logos and images are served from there. They caused a 500 
when displaying inline. (resulting in borken images).

> > recently. We now rely on this file, inside the files dir, for security,
> > meaning if you remove that file, you might be less secured. We must at
> > least document this.
>
> Removing the file is irrelevant - you remove it and Drupal will recreate
> it during the next file upload. You'd have to zero-byte it instead.

Yes. echo '' > files/.htaccess did the trick.


Still teh fact remains that we (Drupal) rely on common set-ups and with that, 
apparently break some rather exotic set-ups. I m not sure if this is good or 
bad, or if we should care. I am not trying to fix anything, nor trying to 
tell we should change anything. I only wanted to point this out. Point out 
that our model is not yet full-proof. 

Bèr

-- 
 PGP ber at webschuur.com
  http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc


Drupal upgrade repareert kritiek beveiligingslek:
 http://help.sympal.nl/drupal_upgrade_repareert_kritiek_beveiligingslek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060609/4895f033/attachment.pgp