Linux: «передача» / зеркалирование разрешений только для чтения для символических ссылок (для веб-сервера) - PullRequest
0 голосов
/ 03 марта 2011

Пожалуйста, позвольте мне объяснить, что я имею в виду под вопросом:

Это контекст: я пользователь веб-сервера, где у меня установлен phpicalendar;затем я выбираю каталог, скажем /webroot/mylogin/phpicalendar/mycals для размещения моих .ics текстовых файлов календаря.

РЕДАКТИРОВАТЬ: Ранее, вместо '/webroot', я использовал '/root' - но я действительно не имел в виду Linux '/root'каталог - я просто хотел использовать его в качестве замены для реального местоположения на веб-сервере (так что он служит просто точкой отсчета).В противном случае, под общей точкой отсчета я подразумеваю просто /webroot = /media/some/path ..

Затем я могу ввести этот каталог в phpicalendar config.inc.php:

$configs = array(
 'calendar_path'        => '/webroot/mylogin/phpicalendar/mycals;
 ...

Затем phpicalendar пробежит по этому каталогу, возьмет там файлы .ics (скажем, mycal.ics и mycal2.ics) и отобразит их - пока все хорошо.

Дело в том, что я хотел бы добавить второй календарь-каталог, расположенный на том же веб-сервере, но там, где у меня есть права только для чтения, скажем /webroot/protected/cals.Я знаю, что у меня есть разрешения на чтение, потому что я могу сделать в оболочке, скажем,

$ less /webroot/protected/cals/maincal.ics

, и я могу читать содержимое нормально .. Итак, теперь:

  • Если я введу/webroot/protected/cals как 'calendar_path', phpicalendar может читать и отображать файлы там (скажем, 'maincal.ics', 'maincal2.ics') без проблем
  • Однако, phpicalendar может иметьтолько один 'calendar_path', поэтому я могу использовать либо защищенные календари, либо свои настраиваемые календари - но не оба
  • Итак, я подумал, что я могу использовать символическую ссылку защищенных календарей в своемнастраиваемый каталог - и получите лучшее из обоих миров :)

Итак, вот фрагмент оболочки того, что я бы сделал

$ cd /webroot/mylogin/phpicalendar/mycals
$ ls -la 
drwxrwxrwx  2 myself myself 4096 2011-03-03 12:50 .
-rw-r--r--  1 myself myself 1234 2011-01-20 07:32 mycal.ics
-rw-r--r--  1 myself myself 1234 2011-01-20 07:32 mycal2.ics
...

$ ln /webroot/protected/cals/maincal.ics .    # try a hard link first
ln: creating hard link `./maincal.ics' => `/webroot/protected/cals/maincal.ics': Invalid cross-device link'

$ ln -s /webroot/protected/cals/maincal.ics .                  # symlink - works
$ ln -s ../../../protected/cals/maincal.ics relmaincal.ics  # symlink via relative
$ ln -s mycal.ics testcal.ics                               # try a symlink to a local file

$ ls -la                                                    # check contents of dir now
drwxrwxrwx  2 myself myself 4096  .
-rw-r--r--  1 myself myself 1234  mycal.ics
-rw-r--r--  1 myself myself 1234  mycal2.ics
lrwxrwxrwx  1 myself myself   21  testcal.ics -> mycal.ics
lrwxrwxrwx  1 myself myself   56  maincal.ics -> /webroot/protected/cals/maincal.ics
lrwxrwxrwx  1 myself myself   66  relmaincal.ics -> ../../../protected/cals/maincal.ics

Хорошо, вот что происходит:

  • less maincal.ics работает на оболочке
  • less relmaincal.ics завершается с ошибкой 'relmaincal.ics: No such file or directory' (, даже если автозаполнение оболочки для относительного пути работало во время выполнения символической ссылкикоманда! )
  • Когда вы откроете phpicalendar сейчас, он отобразит mycal.ics, mycal2.ics и testcal.ics (и они будут работать)
    • however, maincal.ics и relmaincal.ics будут не анализироваться или отображаться

Теперь - возможно, PHP не может разрешать символические ссылки;однако я полагаю, что ситуация такова:

  • Когда я делаю less maincal.ics - это myself, кто пользователь, который имеет разрешение на чтение для /webroot/protected/cals
  • phpicalendar (таким образом, пользователь веб-сервера Apache) в противном случае может также получить доступ к /webroot/protected/cals только для чтения, когда заданный «жестко заданный» путь
  • phpicalendar также способен читать локальные символические ссылки нормально

Таким образом, я подозреваю, что проблема заключается в следующем: при попытке чтения символических ссылок на защищенные программы пользователь, который виден оболочке во время этой операции, является веб-пользователем Apache, который затем не получает разрешения на доступ к символическая ссылка в защищенное место / cals!

Дело в том, что я могу легко скопировать файлы .ics локально;однако они меняются кем-то другим, поэтому я бы предпочел символическую ссылку.

И мой вопрос : могу ли я сделать какую-то хитрость, чтобы когда phpicalendar / Apache пытался получить доступ к символической ссылке на protected / cals, он «думал», что это локальныйfile - и в противном случае содержимое защищенного файла / cals «передается» обратно в phpicalendar / Apache ??Я думаю, что я думаю о чем-то:

$ mkfifo mypipe
$ ln -s mypipe testpipe.ics
$ cat ./testpipe.ics                                 # in one terminal
$ cat /webroot/protected/cals/maincal.ics > mypipe      # in other terminal

... что в противном случае (я думаю) решило бы проблему с разрешениями - за исключением того, что я не хочу cat вручную;это должно быть сделано в фоновом режиме, каждый раз, когда приложение запрашивает чтение testpipe.ics :)

Хорошо, заранее спасибо за любые комментарии по этому поводу - с нетерпением жду некоторых,
ура!

Ответы [ 2 ]

0 голосов
/ 03 марта 2011

Начните с проверки, может ли пользователь Apache просматривать ваши календари:

you@host $ sudo -i -u <apache-user> -s /bin/bash
apache@host $ less /root/protected/cals/maincal.ics
0 голосов
/ 03 марта 2011

Умм, я действительно сомневаюсь, что учетная запись, под которой работает веб-сервер, может читать что угодно в /root.Этот каталог обычно находится в режиме 0700, пользовательский корень, корень группы или что-то очень похожее на него, то есть доступ без полномочий root запрещен.Если вы используете веб-сервер от имени пользователя root, права на чтение файла - это наименьшая из ваших проблем ...

Тогда лучше всего разместить файлы календаря только для чтения где-нибудь в открытом доступе и использовать символическую ссылку наэто место из любого места в каталоге / root, к которому вы хотите иметь доступ.

...