Неправильное употребление движения-r *

В соответствии с вашей конфигурацией, у вас есть два серверных{...} блока, которые точно такие же. Поэтому, прежде чем я начну объяснять, что не так с вашей конфигурацией, вы должны предоставить более подробную информацию. Смотрите ниже некоторые советы по устранению неполадок.

А пока я напишу здесь свои и выделяю несколько директив , которые имеют значение.

Моя /etx/nginx/conf.d/default.conf выглядит следующим образом

server {

  # Replace this port with the right one for your requirements
  listen 80;

  # Multiple hostnames separated by spaces.  Replace these as well.
  server_name mydomain.nl;

  root /var/www/mydomain.nl/public_html/;

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;

  index index.php index.html;

  location / {
    # This is cool because no php is touched for static content.
    try_files $uri $uri/ /index.php;
  }

  location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ {
    expires max;
  }

  location ~* \.php$ {
    try_files $uri =404

    fastcgi_intercept_errors on;

    fastcgi_index   index.php;
    fastcgi_pass    unix:/var/run/php5-fpm.sock;

    include fastcgi_params;

    fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;
    fastcgi_param   SCRIPT_NAME        $fastcgi_script_name;
  }

  location ~ /\.(ht|ssh) {
    deny  all;
  }

  location /status {
    include fastcgi_params;
    fastcgi_pass    unix:/var/run/php5-fpm.sock;
  }

}

Следующие директивы важны:

имя_сервера mydmaiin.nl; <-- Эта директива уникальна для каждого блока сервера.

root /var/www/mydomain.nl/public_html/; <-- Это корень, который содержит ваш сайт / данные.

Остальное тривиально.

Итак, давайте возьмем файл /etc/php-fpm.d/www.conf и посмотрим. Вы выбрали файловый сокет

listen = /var/run/php-fpm/php-fpm.sock <-- php-fpm будет взаимодействовать с nginx через этот файл. Так что это мой www.conf файл, если только вы что-то не пропустили. Я отфильтровал все закомментированные строки. Так что это те строки, которые не закомментированы.

[www]
listen = /var/run/php5-fpm.sock
listen.allowed_clients = 127.0.0.1
listen.owner = nginx
listen.group = nginx
listen.mode = 0666
user = apache
group = apache
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
slowlog = /var/log/php-fpm/www-slow.log
security.limit_extensions = .php
php_admin_value[error_log] = /var/log/php-fpm/www-error.log
php_admin_flag[log_errors] = on
php_value[session.save_handler] = files
php_value[session.save_path] = /var/lib/php/session

Устранение неполадок

1) Смотрите разрешения на каталоги. В данном случае /usr/share/nginx/html

2) См. журнал ошибок php-fpm. Посмотрите, нормально ли загружается конфигурационный файл, запустив

php-fpm -y /etc/php-fpm.conf

3) Измените log_level = debug в /etc/php-fpm.conf

4) Возвращайтесь с более подробной информацией!

-2
04.04.2014, 23:50
2 ответа
[1120985] Во-первых, [1121391]chmod go-r [1121392] не удаляет разрешения на запись, а удаляет разрешения на чтение. Содержимое [1121393]/[1121394] - это в первую очередь каталоги; в каталогах разрешение на чтение означает, что вам разрешено его перечислять. Например, [1121395]ls /bin[1121396] теперь даст разрешение запрещено (за исключением владельца каталога и корня, конечно, в этом случае владелец корня).

Если это была опечатка, и вы имели в виду [1121397]chmod go-w[1121398], то вы действительно удалили разрешение на запись. Вероятно, единственным каталогом, в котором было разрешение на запись для [1121399]g[1121400] roup или [1121401]o[1121402]ther был [1121403]/tmp[1121404]; вы должны это исправить.

К счастью, вы не включили [1121405]-R[1121406] (рекурсивный) в свой [1121407]chmod[1121408], так что это довольно легко исправить: Просто сравните [1121409]ls -l /[1121410] на тестовом сервере с [1121411]ls -l /[1121412] на аналогичном сервере. Используйте [1121413]chmod[1121414], чтобы установить права доступа обратно, как должно быть.

Обратите внимание, что chmod будет следовать за симлинками, поэтому, если они есть в вашем корневом каталоге, вам нужно будет подтвердить их отдельно.

Наконец, кажется, что вы не понимаете модель прав доступа Unix. Каждый файл и каталог имеет [1121415]одного [1121416] пользователя (владельца) и [1121417]одну [1121418] группу. Владелец может иметь права на чтение, запись и/или выполнение в файле/директории. Это то, что [1121419]chmod u=...[1121420] устанавливает. Все члены группы могут иметь один и тот же набор разрешений ([1121421]chmod g=...[1121422]). Наконец, все остальные (остальные) получают одно и то же множество ([1121423]chmod o=...[1121424]).

Пример:

t[1121426] тип файла: пустой для простых файлов, [1121427]d[1121428] для каталогов, [1121429]l[1121430] для симлинков, [1121431]c[1121432] для символьных устройств, [1121433]p[1121434] для именованных труб, [1121435]b[1121436] для блочных устройств, и еще несколько, наверное, я забыл.

acl[1121438] будет [1121439]+[1121440] если в этом файле есть ACL, вы можете использовать [1121441]getfacl[1121442], чтобы увидеть его.

[1121443]1[1121444] Я не пометил счетчик ссылок; если вы сделаете жесткую ссылку на файл, оба имени покажут 2. Добавьте еще один, и они покажут 3 и т.д.

Поле разрешений - это три символа для владельца (пользователя); три для группы; и три для других. Владелец (пользователь) может [1121445]r[1121446]ead и [1121447]w[1121448]w[1121448] r[1121448] обработать файл, но не выполнить (так как вместо [1121451]x[1121452] там есть [1121449]-[1121450]). Члены группы [1121453]Debian-exim[1121454] могут читать файл, но не получают никаких других разрешений. Люди, которые не являются ни владельцами, ни членами Debian-exim, не получают разрешений на этот файл.[1121004].

7
28.01.2020, 05:14

chmod go-r *[1121322] вообще не затрагивает специальные группы. Она просто влияет на права первичных групп и "других". Первичная группа для всех в [1121323]/[1121324] должна быть [1121325]root[1121326]. Так что это вообще ничего не меняет, так как корень может делать всё, что захочет.enter image description here

Остальные учётные записи обычно не читают содержимое каталогов в [1121327]/[1121328], так как они знают свои пути. Доступ к этим путям все еще возможен (благодаря разрешению [1121329]x[1121330]).

Имеют ли до сих пор группы, которые вы создали, явное разрешение на чтение в этих каталогах, зависит от того, используются ли ACL. Если ACL присутствует, то выходной сигнал [1121331]ls -l[1121332] изменяется с

на

Содержимое ACL можно увидеть с помощью [1121333]getfacl[1121334].

Главный вопрос: зачем препятствовать группам читать каталоги в [1121335]/[1121336]?[1120914].

2
28.01.2020, 05:14

Теги

Похожие вопросы