is_dir возвращает false для символических ссылок в apache

Я запускаю стороннее PHP-приложение в своем локальном стеке AMP на своем Mac. Недавно я купил новый Mac Mini с Lion и пытаюсь его настроить. Мой предыдущий компьютер был MB air с MAMP. Теперь я использую встроенный apache/php и доморощенную установку MySQL.

Вот моя проблема: у меня есть каталог с символическими ссылками. Эти символические ссылки относятся к каталогам, и приложение PHP проверяет их с помощью is_dir().

В моей установке Lion AMP этот is_dir() не работает. Та же установка на моем Snow Leopard MAMP is_dir() отлично работает с моими символическими ссылками.

Вот где становится любопытнее. Если я делаю php -a (интерактивный режим командной строки php) и делаю is_dir() в тех же каталогах, он возвращает true. Он возвращает false только в контексте запроса apache. Это заставляет меня думать, что это как-то связано с тем, что пользователь apache (то есть _www) не может получить доступ к символическим ссылкам. Устранение неполадок выходит за рамки моей компетенции.

Другие примечания:

  1. Да, я включил FollowSymLinks в моей конфигурации apache, и фактически каталог, в котором находятся рассматриваемые символические ссылки, сам является символической ссылкой. У апача с этим проблем нет. Пока не используется PHP is_dir().
  2. Нет, я не могу редактировать приложение PHP и просто вернуться к is_link() и readlink().
  3. Точно такая же установка работала на моей установке Snow Leopard/MAMP.

Любые идеи?


macos php apache symlink osx-lion
person Rob    schedule 07.08.2011    source источник
comment
Разве символические ссылки не считаются файлами до тех пор, пока вы не перейдете к ним?   -  person smdvlpr    schedule 07.08.2011

Ответы (3)


arrow_upward
1
arrow_downward

Я видел ваш комментарий об изменении их на 777, но все еще задаюсь вопросом, почему это не работает. Мое решение ниже может вам не помочь.

РЕДАКТИРОВАТЬ:

Если у вас есть доступ к /etc/apache2/httpd.conf,
редактируйте его через sudo vi /etc/apache2/httpd.conf.
Затем измените эти 1 из этих строк или обе.

User _www
Group _www

Вот пример моего списка каталогов.

ace:remote-app ace (git::master)$ ls -al
total 72
drwxr-xr-x  24 ace  staff   816  7 Aug 00:24 .
drwxr-xr-x  11 ace  staff   374  4 Aug 13:46 ..
drwxr-xr-x   3 ace  staff   102 12 Jul 17:06 .bundle
drwxr-xr-x  14 ace  staff   476  7 Aug 02:29 .git
-rw-r--r--   1 ace  staff   100  1 Aug 19:20 .gitignore
-rw-r--r--   1 ace  staff     9  1 Aug 19:20 .rspec
drwxrwxr-x  10 ace  staff   340 14 Jul 15:58 public

Теперь мой общий каталог имеет права доступа 775, что означает, что owner и group имеют полные права доступа, в то время как другие пользователи могут только читать и выполнять.
Это зависит от того, хотите ли вы, чтобы пользователь apache стал ace вместо _www по умолчанию, или чтобы группа apache стала staff из по умолчанию _www.

После того, как вы решили, что изменить, перезапустите apache.

/usr/sbin/apachectl graceful

Теперь у вашей страницы должен быть доступ к каталогам и файлам.
Следует отметить, что вам нужно изменить владельца для файлов, которые уже были написаны вашей веб-страницей, поскольку они имеют _www:_www прав собственности, и у вас не будет доступа. им после перезапуска.
Вы можете изменить их нового владельца через это, -R чтобы сделать его рекурсивным.

sudo chown -R newapacheuser:newapachegroup <path>
person ace    schedule 07.08.2011
comment
Спасибо, это помогло. Я изменил пользователя и группу в httpd.conf на свое имя пользователя и группу. Не совсем идеально, но это просто для моего местного развития, поэтому я могу с этим жить. Я до сих пор не уверен, почему установка 777 не сделала так, чтобы пользователь _www имел доступ, но я просто собираюсь двигаться дальше и перестать возиться с этим. Спасибо за вашу помощь. - person Rob; 07.08.2011

arrow_upward
1
arrow_downward

Вы проверяли разрешения/владельца?

Из руководства по PHP: Примечание: результаты этой функции кэшируются.

person robert    schedule 07.08.2011
comment
я изменил разрешения для этих символических ссылок и связанных с ними каталогов на 777. Этого должно быть достаточно, не так ли? - person Rob; 07.08.2011
comment
Возможно, есть разница в php.ini для настроек CGI и командной строки. Также над CGI стоит Apache. Если из CLI работает, а из CGI нет, то я предполагаю, что проблема с конфигурацией. - person robert; 07.08.2011

arrow_upward
0
arrow_downward

У меня была аналогичная проблема. Я создал следующую ссылку:

cd /home/mike/uploads
ln -s ./data /sites/www.test.com/docroot/data

Затем я создал файл test.php в /sites/www.test.com/docroot, который просто сделал следующее:

$dir = "/sites/www.test.com/docroot/data";
"is_dir\t\t" .is_dir($dir) ."\n";

Когда я запускал test.php из командной строки, он отображался как is_dir как True, но когда я загружал test.php из браузера через apache, это было False.

Я зашел на /sites/www.test.com/docroot/data и сделал

chmod -R 755 .

Это ничего не изменило. Затем я понял, что родительский фактический каталог с символической ссылкой нуждается в правильном наборе разрешений (/home/mike/uploads). Я сделал chmod в этом каталоге, и все заработало!

person targnation    schedule 17.09.2013