Форум PHP

Элементарные понятия про 4+2+1 у меня есть. Хотя не понимаю, почему иногда cmod бывает четырехзначный. Сообразил только пока, что четырехзначный с 0777 это, наример, то же, что и 777.
Но самое главное не понимаю:
Кто такой владелец, как он идентифицируется? Что еще за группа пользователей?
Чем отличается чтение от выполнения?
И как мне сделать, чтобы файлы в директории открывались, создавались, записывались и читались скриптами (при администрировании с браузера), но не читались через http?

Кто знает как на групу фаилов задавать права ?

Права в UNIX или для просмотра этих файлов посетителями Web-сайта?

Для просмотра посетителями сайта.

>почему иногда cmod бывает четырехзначный. Сообразил только
>пока, что четырехзначный с 0777 это, наример, то же, что и 777.
1) Дело в том, что права доступа задаются восьмеричным числом (0-7), в PHP восьмиричные числа предваряются 0, чтобы отличать их от десятичных.
2) Владельца файла можно посмотреть функцией chown - это пользователь UNIX которому принадлежат файлы - он имеет право менять права доступа к файлу. В Windows тоже можно создать несколько пользователей и у них будут свои файлы, которые другие пользовтели могут посмотреть только с разрешения владельца - здесь точно так же под каждого клиента хостинг заводит отдельно UNIX-пользователя который может манипулировать своими файлами и не может трогать чужих.
>Что еще за группа пользователей?
Пользователи объединяются в группы. Это сейчас, когда взрывообразно развивается PC, это кажется какой-то дикостью - зачем на машине создать какие-то группы, когда за ней работает один человек? На самом деле совсем недавно компьютеры представляли из себя мощные майнфреймы или рабочие станции, стоимостью милионы долларов, к которым цеплялись терминалы (клавиатура и монитор) штук эдак 200 и когда такая прорва пользователей скапливалась на машине и работала одновременно над несколькими проектами, то группы пользователей были даже очень кстати - удобно менять права доступа сразу всей группе.
>Чем отличается чтение от выполнения?
В Windows исполняемые файлы обозначаются приданием им соответствующего расширения - exe. В UNIX исполняемый файл может не иметь никакого расширения - для того, чтобы его запустить у него должен стоять бит исполнения (1), причём можно разграничить исполнение - например разрешить исполение файла для владельца и группы, но запретить для всех остальных. Исполнение для директорий это вот что. Если выставлен режим чтения, то можно получить список файлов в директории, а если режим исполнения, то можно заходить в директорию. Т.е. если права на чтения выставлены, а на исполнение нет, то по командой ls можно получить список файлов, но зайти в директорию нельзя... но это всё актуально когда вы сидите непосредственно на UNIX машине или через SSH...
>И как мне сделать, чтобы файлы в директории открывались,
>создавались, записывались и читались скриптами (при
>администрировании с браузера), но не читались через http?
HTTP уже не имеет отношения к файловой системе - здесь следует работать с Web-сервером - настраивается это при помощи конфигурационного файла .htaccess, который располагается в нужной директории. Подробности -
http://www.softtime.ru/info/articlephp.php?id_article=25
http://www.softtime.ru/info/articlephp.php?id_article=27

Короче говоря, получается, что для администрирования сайтом в некой директории admin , где создаются, читаются и записываются файлы чкрмптом php и одновременно эти скпипты запускались, мне необходимо выставить 777? Так? Потому что при 666 нет доступа с браузера, а при 555 или 755 не открываются и не создаются файлы скриптом. Правильно?
И вы говорите, что это не итмеет никакого влияния на безопасность?
Но меня смущает то, что создаваемые текстовые служебные файлы могут быть прочитаны, если знать х имена. Не то, чтоб там было что-то тайное, но как-то неуютно) . Я , конечно, уже читал про .htaccess, но вроде такой функции там не видел. Если я даже, допустим, все служебные файлы заброшу в отдельную директорию и закрою у ним доступ через .htaccess, то будут ли они достуаны тем же скриптам?

Таким образом, задаса сводится к тому, чтобы файлв читал скрипт, но не посетитель, а я бы при желании посмотрел их, копируя через фтп.

>Короче говоря, получается, что для администрирования сайтом
>в некой директории admin , где создаются, читаются и
>записываются файлы чкрмптом php и одновременно эти скпипты
>запускались, мне необходимо выставить 777? Так? Потому что
>при 666 нет доступа с браузера, а при 555 или 755 не
>открываются и не создаются файлы скриптом. Правильно?
Нет права доступа 666, 555 и тому подобное никак не влияют на возможность их просмотра из браузера. Если Web-сервер имеет право читать этот файл и посетитель получит к нему доступ. Права действуют только на UNIX-сервере. Мда... сам прочитал и понял, что следует добавить. Web-сервер - это программа, которая генерирует Web-содержимое для клиента, она сложная и большая, поэтому для неё выделяют отдельную машину, которую, чтобы жизнь мёдом не казалась тоже называют сервером - на ней стоит операционная система UNIX - в ней есть файловая система с правами доступа (0777) и эти права не одно и тоже, что показывает Web-сервер, так как ему на эти права плевать - у него своё представление о том, что должен видеть посетитель, а что не должен.
>И вы говорите, что это не итмеет никакого влияния на
>безопасность?
>Но меня смущает то, что создаваемые текстовые служебные
>файлы могут быть прочитаны, если знать х имена. Не то, чтоб
>там было что-то тайное, но как-то неуютно) . Я , конечно,
>уже читал про .htaccess, но вроде такой функции там не
>видел. Если я даже, допустим, все служебные файлы заброшу в
>отдельную директорию и закрою у ним доступ через .htaccess,
>то будут ли они достуаны тем же скриптам?
Служебные файлы нужно все закрывать, даже если они кажутся безопасными - взломщик может найти там нужную ему информацию, нужная вам защита описывает по ссылке (в конце)
http://www.softtime.ru/info/articlephp.php?id_article=27

>>Нет права доступа 666, 555 и тому подобное никак не влияют на возможность их просмотра из браузера.

Разве? Ведь я лично выставлял 666 на ФТП клиенте. После этого при обращении к файлвм этой директории браузер выдает такое, например:

Forbidden
You don't have permission to access /admin/ip.txt on this server.

Это тем более загадочно, что по умолчанию все права на директории стоят 755. Но при этих правах у меня не работала функция fopen. Хотя уже при этом файлы просматривались. Значит для просмотра нужно право на исполнение?

Статьи по ссылкас я посмотрел. Но не понял этого:

Файл с паролями создается утилитой htpasswd.exe. Если у Вас на машине установлен WEB-сервер Apache, то данная утилита находится в директории с установленным Apache-ем в подкаталоге bin.

У меня вроде Апаче, но подкаталога бин не вижу. Хотя htaccess действует.
Куда теперь устанавливать htpasswd?

>Разве? Ведь я лично выставлял 666 на ФТП клиенте. После
>этого при обращении к файлвм этой директории браузер выдает
>такое, например:
Это 100%, если хостинг использует apache (а не какой-то специальный сервер, который реагирует на права доступа в файловой системе), тем более права 666 разрешают просмотр и редактирование файла любому пользователю.
>Это тем более загадочно, что по умолчанию все права на
>директории стоят 755. Но при этих правах у меня не работала
>функция fopen. Хотя уже при этом файлы просматривались.
>Значит для просмотра нужно право на исполнение?
А владельцем директории и скрипта кто были - один пользователь или разные?
> У меня вроде Апаче, но подкаталога бин не вижу. Хотя
>htaccess действует.
Он должен быть в директории bin, которая в свою очередь расположена в корневой директории Web-сервера apache - т.е. что то вроде C://www/apache2/bin.

>Если я даже, допустим, все служебные файлы заброшу в
>отдельную директорию и закрою у ним доступ через .htaccess,
>то будут ли они достуаны тем же скриптам?
Да, скриптам файлы будут доступны, им .htaccess не указ.

Так может тогда не дурить головы и не использлвать htpasswd ? Оставить в директории admin только файлы php с формами (в том числе и для пароля), а служебные файлы засунуть в закрытые хтаккессом директории . Так будет нормально? Сайт у меня не комерческий. Может этого хватит "от честных людей"? :)

Конечно, в вашем случае именно так и стоит поступить... пароль нужен если вы сами захотите служебные файлы просматривать через браузер.

Большое спасибо!
Хотя, честно говоря, насчет этих чмодов так и остался туман. просто помню, что при устаноке нкоторых порталов , гостевых книг требуется выставлять права. Где 777, где 666. Вроде это связано с MySQL, так это?

Нет с MySQL это не связано - это отдельный сервер и там как раз с правами доступа проблем обычно не возникает, обычно права доступа требуются для файловых вариантов Web-приложений - там дейттвительно это актуально.

Что означает "для файловых вариантов Web-приложений ". Может, что-тог простое, но я не совсем владею дискурсом. Не могли бы Вы для илюстрацмии дать ссылку, что ли.
Я убедился , по крайненй мере, что fopen не открывал файл для записи, но только для чтения, пока я не поменял доступ к файлу с 644 на 666.

Файловый вариант означает, что Web-приложение хранит необходимую ему информацию в файлах (чаще текстовых), а не в базе данных.

>а служебные файлы засунуть в закрытые хтаккессом директории .
А служебные файлы это какие?

И почему не следует использовать htpasswd?
Htpasswd используется вместе с htaccess. По ссылке наша статья о запароливании директорий.

И почему не следует закрывать админ?
Ведь если админ не будет закрыть в него смогут входить кто захочет. Как Вы ограничите доступ?

PS: Меня в общем-то смутила Ваша фраза о том, что htpasswd не надо использовать…
И я не понял: будете Вы запароливать админ или нет. А если будете, то как?

http://www.softtime.ru/info/articlephp.php?id_article=27

Если используется файловые варианты Web-приложений, файлы в которых редактируются по FTP, то через Web максимум что можно сделать это утащить сами служебные файлы, я так понял здесь именно такой вариант, поэтому достаточно просто запретить доступ к ним, так как администратору Web-доступ не требуется...

Нет, у меня не совсем тот вариант, видимо.
Я именно делаю управление контентом сайта через браузер. В директории admin находятся рнр - файлы ч формами для записи информации в текстовые файлы на сервере, а те, в свою очередь используются для формирования страниц сайта. Все это по Фтп делать неудобно, так как рнр скрипты сами все оформляют, нумеруют, ставят в свое место.. ну и тд.. По-моему, это понятно. Да ведь аналогичный подход действует и в известных портальных стстемах типа Постнюк. Кстати, именно там я встретил впервые это требование установки определенных прав доступа к некоторым файлам и директориям. Система мне потом показалась громоздкой и слишком на себя завязывающей. Поэтому я отказался и делаю свою - проще и по виду приятнее. И я хоть знаю, где там и что и откуда у меня растет и торчит:)
Но там ведь, кстати, тоже htpasswd вроде не используется.
Кстати, я столкнулся с проблемой htaccess. Или я что-то не понимаю. Обрадовался, что есть функция запрета доступа к файлам с определенным расширением. Это то, что мне и надо. Ведь файлы, которые я не хочу, чтоб были доступны у мяня txt .То есть я записал
<Files ".(txt)$">
deny from all
</Files>
и надеялся, что прав доступа к текстовым файлам не будет. Но ошибся. Они доступны. Но в принципе htaccess действует. Если в директории его оставить с просто deny from all, то доступа к файлам действительно нет. Может ли быть так, что его действие ограничено?

Ага это запрет по регулярному выражению, но синтаксис у него должен быть следующим

<Files ~"\.(txt)$"> deny from all </Files>

Во-первых, синтаксис не я придумал, а он указан в статье
http://www.softtime.ru/info/articlephp.php?id_article=25
Во-вторых, и с Вашим синтаксисом не работает.

>Если используется файловые варианты Web-приложений, файлы в которых редактируются по FTP, то через Web максимум что можно сделать это утащить сами служебные файлы...

А если все тоже самое, но используются не текстовые файлы, а php файлы, в которых все данные в виде массивов, доступ я к ним получаю через include(), а при редактировании переписываю весь файл, вместе с синтаксисом php.....
Ясно, что через WEB, доступа к их содержимому не получишь (или я лшибаюсь?), а вот как мне ограничить к ним доступ (предполагается, что "вредитель" как-то узнал имя файлов) скриптам, ну например которые запускаются не из етой же папки или папки на уровень выше. Установка прав, типа 0700 не подойдет - мои выполняются как noname. По большей части меня волнует их перезапись. Чтение не принцмпиально.

Я не говорю, что не следует использовать, но все, как говорится, имеет свою цену . Надо отдельно разбираться... Тут ещеобнаружилось, что он должен быть установлен в Апаче в дректории некой bin... Самому устанавливать? Вдруг это потянет какие-то проблемы.... Может оно и интересно, но со временем и на досуге)
Пока что, как я вижу, не все это дело используют. На известных портальных системах обычный вход через формы - логин и пароль. То емсть я не отказываюсь, конечно, от пароля как такового. Просито этого, видимо, хватит. Очень сомневаюсь, что кто-то сильно будет ломать холову, как сломать мне сайт, содержащий только статьи, новости и публикации. Но, с другой стороны, и чересчур открытым все делать не хочется - вдруг кто-то скуки ради захочет похулиганить.
Я помню такой случай, как моя знакомая прослыла великим хакером, тогда как делов-то было угадать нахзвание файла:)

А "служебными файлами" (может неправильно) я называю текстовые файлы в которых хранятся название засылаемой на сервер статьи, автор, дата, содержание, текущий id и тд - все в отдельных файлах. Потом это все копируется в паку под своим номером и используется скриптом для формирования страницы. То есть все вроде нетайное, но как бы кухня, которая не хочется, чтоб торчала на виду)

>Тут ещеобнаружилось, что он должен быть установлен в Апаче в
>дректории некой bin... Самому устанавливать?
Нет этот файл входит в стандартную поставку дистрибутива. Выбор метода авторизации каждый выбирает сам, обычно принято, чтобы посетителям сайта предоставлять Web-интерфейс для авторизации, а администрации и обслуживающему персоналу - всплывающее окно, как это описывается в статье.

Может он и входит, но куда н вошел и откуда его попросить выйти, я не понимаю:)

>На известных портальных системах обычный вход через формы - логин и пароль.
Отображение со стороны клиента одно и тоже. Это может быть авторизация через PHP или средствами Apache (htaccess и htpasswd) или еще чем. Окно для ввода пароля выдает браузер и по нему нельзя определить какая защита используется.
Защита с помощью сервера проще в реализации чем защита, например на PHP. Так как в случае защиты с помощью Apache (htaccess и htpasswd) всего то требуется выполнить несколько несложных действий, а все остальное возьмет на себя сервер.

Если писать защиту самому, то и все алгоритмы нужно продумывать и писать самому. Отсюда сложности с реализацией.

И я так и не понял как осуществляется защита админа…
У Вас есть папка админ? Когда Вы в нее входите Вы вводите какой либо пароль?
Ведь даже защитив тестовые файлы с помощью .htaccess – эти файлы все равно доступны скриптам из Вашего админа. А не может Вашим админом воспользоваться кто то другой? Я вот про что спрашиваю…


> принято, чтобы посетителям сайта предоставлять Web-интерфейс для авторизации
А даже и с WEB-интерфейсом все равно потом вылетает тоже самое окно авторизации из браузера. Заголовки то одни и те же посылаются…

>>Окно для ввода пароля выдает браузер и по нему нельзя определить какая защита используется.

Не уверен. Даже уверен, что Вы не правы. Окна разные.

>>У Вас есть папка админ? Когда Вы в нее входите Вы вводите какой либо пароль?

Я же вроде говорил, что пароль есть. Но бех htacess, а через обычную форму типа: <input name="Name" type="password" value=""> Без пароля войти в папку admin нельзя. Просто я раньше в этой же директории, кроме php файлов держал и гекстовые файлы, в которые записывается информация для последующего копирования, то есть там информация о последней вводимой статье, Я не хочу, чтоб эти текстовые файлы читались, только и всего. Теперь я для них сделал отдельную папку, а в ней htaccess.
Вот только не пойму, почему у меня запрет на все файлы htaccess-ом работает, а определенного расширения, нет. А это было бы удобнее, полскольку текстовые файлы у меня везде и всюду:)

> Вот только не пойму, почему у меня запрет на все файлы htaccess-ом работает, а определенного расширения, нет.
Наиболее вероятно - ошибка в регулярном выражении в файле .htaccess.
Вот этот синтаксис используете?

<Files ".(txt)$"> deny from all </Files>

Перепроверю его сегодня – отпишусь.

И такой синтаксис пробова, и с обратным флэшем перед точкой - все едино. Не действует.

Под вашу задачу можно воспользоваться контейнером FilesMatch, поместите в .htaccess следующие директивы

<FilesMatch "\.(txt)$">    order allow,deny   deny from all </FilesMatch>

При этом проконтролируйте, если вы тестируете на локальном хосте, чтобы в главном конфигурационном файле httpd.conf операция разрешения и запрещения была разрешена для файлов .htaccess

<Directory />     Options FollowSymLinks Indexes     AllowOverride All </Directory>

PS Если что-то не заладится - пишите будем разбираться дальше...
PPS offtop: это 10000 сообщение форума...

Спасибо!!
Этот вариант работает:)

Хм... сам запутался. Сначала не работало, а затем заработало. Странно.

<Files ~ "\.(txt|zip|html)$">
Deny from all
</Files>

Тильда (~) должна включать регулярное выражение для проверки. Хотя вообще то контейнер <Files> не работает с регулярными выражениями - только по имени файла

Синтаксис такой:
Тильда, пробел, кавычка далее все без пробелов и снова кавычка.

Либо вот так, используя подстановочные символы, без включения регулярного выражения. Но получится только на одно расширение файла поставить запрет.

<Files *.txt>    Deny from all  </Files>

* - любая последовательность символов
? - любой одиночный символ.

А если со включением регулярных выражений в директиве <Files> все таки не получится, то значит нужно пользоваться директивой <FilesMatch>, которая работает с регулярными выражениями по умолчанию.