- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Но вопрос же о шаред-хостинге. Ессно под каждого юзера не будет разных прав. Посему должно быть некое "универсальное решение" или, если угодно - правильные настройки (для обеспечения беспроблемной работы) касаемо наследования\передачи прав\владельца.
Решения со стороны хостера: mod_php+mpm_itk или php-fastcgi. Вы наш клиент, насколько я помню :) У нас все работает и создается с владельцем user:user, а значит проблемы с правами и установка chmod 777 для записи не обязательны.
KM.UA, пока ни один мой клиент не хостится на хварте, но я о вас не забываю :)
Фаст-цги - ну его :) а mod_php+mpm_itk - не знаю шо сие (потом покурю), но подозреваю это модули апача (и не обязательно установленные).
Извените потёр..
Вторая страница, а ответ получен только на один вопрос. :(
Повторюсь, перефразирую:
1. Господа админы (хостингов), проясните плз, может ли срипт, запускаемый от владельца "апач" создавать файлы присваивая им владельца "юзер"? В см. можно ли так настроить сервер?
2. Если владелец файла (на моём акке) будет "апач" (точнее "апач:апач") - значит ли это, что другой юзер, со своего акка может прочитать\переписать этот файл (т.е. может получить какой-нить доступ)?
3. Ваше мнение - правильно ли, что на шаред-хостинге юзеровские скрипты создают файлы делая их владельцем "апач"? Правильно ли, что они при этом не имеют доступ к файлам (в каталоги) владельца "юзер"?
Поясню к чему я это... Много скриптов (CMS) создают\изменяют файлы в процессе работы (например, сайтмапы, хтакцесс и тд. Не говоря уже о текстCMS и скриптов работающих с файлами). При этом, если каталог (корневой!) будет не доступен скриптам - они не смогут создать нужные файлы. Делать владельца корневого каталога (и рекурсивно) "апач"? Тогда юзер не сможет получить доступ к файлам\каталогам (ни чмодить, ни удалять).
К тому же есть сомнения в безопасности (см п2).
Попрошу высказаться конструктивно, без флуда и тп.
1. Господа админы (хостингов), проясните плз, может ли срипт, запускаемый от владельца "апач" создавать файлы присваивая им владельца "юзер"? В см. можно ли так настроить сервер?
Можно настроить чтобы апач запускался от юзера, тогда и файлы будут создаваться с владельцем юзер.
2. Если владелец файла будет "апач" (на моём акке) - значит ли это, что другой юзер, со своего акка может переписать этот файл?
Если ваши скрипты могут в него писать, значит и другой аккаунт может.
3. Ваше мнение - правильно ли, что на шаред-хостинге юзеровские скрипты создают файлы делая их владельцем "апач"? Правильно ли, что они при этом не имеют доступ к файлам (в каталоги) владельца "юзер"?
Неправильно.
KM.UA, благодарю.
Ну это я знаю, я не знаю именно по передаче прав.
Воот.. значит безопасность на нуле (тут я сомневался, но думал именно так). Т.е. предложение хостера "сделай рекурсивно владельца апач" считать.. ммм.. недействительным.
KM.UA, ещё раз спасибо.
Если ваши скрипты могут в него писать, значит и другой аккаунт может.
щязз. поспешный вывод.
поможет только эксперимент, потому что разных способов это прикрыть имеется достаточно.
mpm-itk решает
Если ваши скрипты могут в него писать, значит и другой аккаунт может.
Вообще-то нет. Речь ведь шла о PHP - там есть и свои механизмы ограничения пользователей.
mpm-itk решает
который сам по себе еще та дырка...
myhand, selinux решает дырку itk