1
0
mirror of https://github.com/php/doc-pl.git synced 2026-03-23 22:52:11 +01:00
Files
archived-doc-pl/security/apache.xml
2024-10-27 10:29:47 +01:00

67 lines
3.1 KiB
XML

<?xml version="1.0" encoding="utf-8"?>
<!-- EN-Revision: ab6785b01ce1006e3a9761988575289f40c9b678 Maintainer: sobak Status: ready -->
<!-- splitted from ./index.xml, last change in rev 1.66 -->
<chapter xml:id="security.apache" xmlns="http://docbook.org/ns/docbook">
<title>Zainstalowane jako moduł Apache</title>
<simpara>
Kiedy <acronym>PHP</acronym> jest używane jako moduł Apache, dziedziczy uprawnienia
użytkownika Apache (zazwyczaj te użytkownika "nobody"). Wpływa to na kilka
rzeczy w kwestii bezpieczeństwa i autoryzacji. Na przykład, jeśli używasz
<acronym>PHP</acronym> do dostępu do bazy danych, o ile ta baza nie ma wbudowanej kontroli
dostępu, będziesz musiał sprawić, aby baza danych była dostępna dla
użytkownika "nobody". Oznacza to, że złośliwy skrypt może uzyskać dostęp i modyfikować
dane w bazie, nawet bez nazwy użytkownika i hasła. Jest zupełnie
możliwe, żeby robot sieciowy natknął się na stronę administracyjną
bazy danych i skasował wszystkie twoje bazy danych. Możesz się
przed tym zabezpieczyć, używając autoryzacji Apache lub stworzyć
własny model dostępu używając LDAP, plików &htaccess; itd.
</simpara>
<simpara>
Często, po ustawieniu zabezpieczeń do tego stopnia, że użytkownik <acronym>PHP</acronym>
(w tym wypadku użytkownik Apache) nie stanowi już dużego zagrożenia,
odkrywa się, że <acronym>PHP</acronym> nie jest już w stanie zapisać żadnych plików
do katalogu użytkownika. Lub że nie może uzyskać dostępu do
ani modyfikować baz danych. Zabezpieczenia powstrzymują przed zapisywaniem
tych dobrych i tych złych plików lub wprowadzaniem dobrych i złych danych do bazy.
</simpara>
<simpara>
Częstą pomyłką bezpieczeństwa czynioną w tym momencie jest pozwolenie Apache
na działanie z uprawnieniami roota albo zwiększenie uprawnień Apache w inny
sposób.
</simpara>
<simpara>
Zwiększanie uprawnień użytkownika Apache do roota jest skrajnie
niebezpieczne i może narazić cały system, więc użycie sudo,
chroot lub uruchamianie jako root w inny sposób nie powinno być nawet rozważane,
o ile nie jesteś specjalistą z zakresu bezpieczeństwa.
</simpara>
<simpara>
Istnieją pewne prostsze sposoby. Używając
<link linkend="ini.open-basedir">open_basedir</link> możesz kontrolować i ograniczać
katalogi, które mogą być używane przez <acronym>PHP</acronym>. Możesz także ustawić
obszary tylko dla Apache, aby zabronić aktywności pochodzącej z sieci dla katalogów
innych niż danego użytkownika.
</simpara>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->