Отправляет email-рассылки с помощью сервиса Sendsay

Информационные технологии для незрячих и слабовидящих

Подписаться Бесплатный дискуссионный лист Подписчиков 1.807
←   Июнь 2008   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


За последние 60 дней 488 выпусков (несколько раз в день)


Сайт листа: http://www.tiflocomp.ru
Открыт: 22-01-2004
Пре-модерация: Нет
Адрес для писем в лист: industry.comp.tiflocomp-list@subscribe.ru

Модератор
Vladimir Dovydenkov

Статистика

1.807 подписчиков
0 за неделю

[TC] Вниманию владельцев сайтов от yadviga.ru

Доброе время суток, уважаемые участники рассылки!

Дамы и господа. В последнюю неделю на указанном хостинге производились
плановые работы по модернизации оборудования и расширению доменных
зон. На данный момент большинство работ завершено и сервера снова
работают. Владельцам сайтов необходимо:

1. изменить параметры доступа по ftp. Теперь в качестве ftp-сервера,
или, по-другому, хоста, нужно указывать домен, находящийся выше вас,
например, для mysmart.go9.ru теперь ftp-хостом будет go9.ru. Остальные
параметры ftp-соединения, включая логины и пароли не изменились.
2. владельцам сайтов нужно проверить атрибуты файлов, велика
вероятность, что некоторые атрибуты оказались сброшенными в chmod 755.
Зайдите в свой аккаунт и установите права chmod 777 для нужных файлов
и директорий заново.

Ответить  
yuniks
Fri, 27 Jun 2008 21:34:31 +0400 (#756313)

 

Ответы:

yuniks:

Это нужно для того, чтобы пользователи могли записывать друг другу в файлы
разную полезную информацию?

Ответить   Дмитрий Падучих Sat, 28 Jun 2008 00:11:43 +0600 (#756323)

 

Доброе время суток, уважаемые участники рассылки и Дмитрий Падучих!
Мне есть, что ответить на письмо от 27 июня 2008 г., 22:11:43

Это рекомендуется делать для некоторых cms, которые не работают при
755, ну а, если что-то надо закрыть, то доступ через веб к
определённой папке можно закрыть через .htaccess обычно так и
делается.

Ответить  
yuniks
Fri, 27 Jun 2008 22:38:44 +0400 (#756329)

 

yuniks:

У каждого пользователя хостинга свой виртуальный сервер?

Ответить   Дмитрий Падучих Sat, 28 Jun 2008 01:07:55 +0600 (#756334)

 

Здравствуйте, Дмитрий.

В терминологии апача -- VirtualHost.
Да, у каждого свой. Апач позволяет на один ip-адрес "назначить" более одного
виртуального хоста.

Успехов. Анатолий.

Ответить   "i_chay" Sat, 28 Jun 2008 05:49:08 +0500 (#756356)

 

i_chay:

А, понятно. Я-то подумал о виртуальном выделенном сервере
(http://en.wikipedia.org/wiki/Virtual_private_server).

[...]

На мой взгляд проблема в том, что 777 (или 666) даёт права на запись для
_всех_ пользователей системы. Защищены ли эти файлы от других пользователей
хостинга в случае, когда они, пользователи, заходят на сервер по ftp, ssh,
выполняют скрипты php, команды cron и так далее?

Ответить   Дмитрий Падучих Sat, 28 Jun 2008 10:00:52 +0600 (#756367)

 

Здравствуйте, Дмитрий.

Это известная проблема.

В смысле "прав доступа к файлу" -- не защищены.
Пользователи хостинга ничем не отличаются от "локальных" пользователей (со всеми
вытекающими последствиями).
Доступ по ftp настраивается так, что пользователь имеет доступ либо только к
своему домашнему каталогу (несмотря на то, что адрес сервера ftp.somehost.xx
может быть общим для всех), либо только к каталогу, который является DocumentRoot
для http-сервера (этот каталог является вложенным в домашний каталог пользователия).
При такой настройке выйти в родительский (т.е. /home) каталог, в случае работы
по ftp, пользователь не может.
Доступ по ssh (и тем более по telnet) на бесплатных хостингах, как правило, запрещен.
На платных, как правило, доступ по ssh разрешен и и в этом случае все обстоит
так же, как на локальной системе с несколькими пользователями: если они узнают,
что некий файл доступен им для записи, то могут выполнить над ним эту операцию.
После этого им, скорее всего, придется искать другой хостинг (плюс санкции, предусмотренные
договором на услуги хостинга; плюс уголовная статья или две).
Обычно там, где есть ssh доступ, домашние каталоги пользователей имеют права
700 (или 701), однако не всегда...

Успехов. Анатолий.

Ответить   "i_chay" Sat, 28 Jun 2008 11:12:01 +0500 (#756387)

 

i_chay:

Да-да, я как раз об этом и пишу, как вы могли заметить. Поскольку наиболее
простой и очевидный механизм защиты с помощью прав доступа предлагается
отключить для удобства использования CMS, мне стало интересно: может, есть
какой-нибудь другой механизм защиты, который применяется на хостингах, чтобы
гарантировать неприкосновенность данных. Про ftp и ssh вы написали, а как
насчёт php, cron и других возможных способов доступа, которые не пришли мне
сейчас в голову, но которые наверняка существуют?

[...]

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

"Пользователь в полной мере ответственен за все действия, производимые под
его регистрационным именем и паролем, включая содержание рассылаемых
материалов или публикации на web-пространстве, принадлежащих example.com".

Ещё, чего доброго, против того бедолаги, которого взломали, санкции и
применят.

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

Ответить   Дмитрий Падучих Sat, 28 Jun 2008 14:17:18 +0600 (#756408)

 

Здравствуйте, Дмитрий.

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

Дело не в cms. Этот механизм является единственно возможным, когда php собран
как модуль апача (соответственно, разработчиками php предусмотрены параметры
конфигурации, ограничивающие активность php). При соответствующих настройках
апача и php вы не сможете что-либо делать вне DocumentRoot. Те, кто разрабатывал
cms? не первый день живут на свете и если какое-то решение предлагается к использованию,
то не ради прикола.
Это касается web-хостинга в чистом виде (без ssh, cron, ftp и т.п.).

Непонятно откуда взялось "гарантировать неприкосновенность"??? Все действия со
своими файлами пользователь осуществляет на свой страх и риск.
Никаких гарантий хостер не предоставляет.

Это, скорее, не способы доступа, а средства доступа. Сами по себе права доступа
к файлу мало что значат. Вопрос в том, какими средствами вы можете воспользоваться,
чтобы с этим файлом что-либо сделать (если вы не можете выполнить команду с консоли,
то какое вам дело, доступен файл для записи или нет).
Соответственно, способ защиты один -- ограничивать доступ к средствам. Это может
быть сделано либо через полный запрет на использование конкретного средства
(например, тех же cron или ssh), либо через конфигурирование самого средства
(например, в php есть соответствующие опции, ограничивающие возможности скриптов
изменять файлы в других каталогах), либо через ограничение доступа к опциям программы
(например, вместо доступа к командному интерпретатору предоставляется доступ
к web-интерфейсу, с серьезными ограничениями возможностей -- например, при формировании
задания cron через web-интерфейс может контролироваться и периодичность выполнения,
и путь к исполняемому скрипту, и тип скрипта и т. д.).
Разумеется, это делается хостинг-провайдером, в первую очередь, для собственной
безопасности.
Пользователи могут это принимать во внимание.

Где существуют? У вас в голове? В системе существует только то, что разрешено
системным администратором, если у вас не так, то вы плохой системный администратор.
Если вы не помните, какие средства у вас в системе доступны пользователям и как
эти средства влияют на безопасность, то это тоже тревожный симптом.

Успехов. Анатолий.

Ответить   "i_chay" Sat, 28 Jun 2008 15:47:04 +0500 (#756430)

 

Доброе время суток, i_chay
Отвечаю на письмо от 28 июня 2008 г., 14:47:04

случае

в технической

К дискуссии так же хотел бы добавить, что письмо носило исключительно
информационный характер, поскольку у некоторых наших подписчиков, мне
это доподлинно известно, есть проекты на обсуждаемом хостинге и
информация была, хочется надеяться, им полезным. Что же касается
назначения прав доступа, то опять же я исходил из рекомендаций,
которые дают разработчики cms, как справедливо заметил Анатолий, у
них достаточно мозгов и опыта, чтобы давать такие рекомендации. После
переконфигурации серверов права доступа оказались сброшены в 755,
поэтому я и написал о том, чтобы пользователи, имеющие проекты на том
хостинге, проверили права доступа и, если ранее работающая cms, вдруг
отказалась работать, искали причину именно в неправильных правах
доступа. Что же касается безопасности, то существует много
возможностей получить доступ к файлам пользователя даже, если права
доступа установлены в 666. Ну и, наконец, для ревнителей безопасности
скажу, что ssh-доступ и пользовательский крон на указанном хостинге,
к сожалению, не предоставляются. В общем, моё письмо, породившее эту
дискуссию, носило информационный характер, а дальше каждый для себя
решает: стоит ли следовать данным рекомендациям, или нет, я ничего не
обрету и ничего не потеряю от того, последует ли кто-либо моим
рекомендациям, или нет.

Ответить  
yuniks
Sat, 28 Jun 2008 15:13:16 +0400 (#756437)

 

Приветствую всех.

Разумеется, именно для этого. Интересно, а для чего еще выставляют права на запись?
Правда, в большинстве случаев Для файлов достаточно 666 (точнее, ??6 -- http-сервер
исполняет скрипты от имени "прочих").
Обычно это файлы с конфигурационными данными cms, которые (данные) невозможно
хранить в базе, но есть необходимость изменять через web-интерфейс; файлы логов,
которые ведет сам движок сайта; раньше, когда бесплатный хостинг с mysql (и т.п.)
был редкостью, многие сайты использовали текстовые файлы в качестве базы данных
(иногда владельцы сайтов используют текстовые базы на хостингах, где сервер баз
данных сбалансирован не в пользу бесплатных/эконом постояльцев).

Успехов. Анатолий.

Ответить   "i_chay" Sat, 28 Jun 2008 05:43:11 +0500 (#756354)