[РЕШЕНО] apache, права, /var/www

[byebyewin]

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

это удаленный сервер хранящий файлы для веба
это директория /var/www/site на удаленном сервере владелец стандартно www-data/www-data
это user/user который часто редактирует файлы в директории /var/www/site (ssh/sudo)
это команда которую приходится делать юзеру после внесения изменений в файлы -  chown -R www....
в доме который построил Джек

По целому ряду причин хочется делать это все "локально", например gedit использовать и т.д.
Из тех способов что я могу придумать все кривые:
- редактировать локально, потом scp
- дать 777 на дир (не рассматриваем)
- sftp - опять же... права на папку.

Как ПРАВИЛЬНО добиться того чтобы и апач и user могли нормально читать/писать в www.
Создать группу общую и дать 770/660?  Ну не могу я сообразить

[uxSkyNET]

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

это удаленный сервер хранящий файлы для веба
это директория /var/www/site на удаленном сервере владелец стандартно www-data/www-data
это user/user который часто редактирует файлы в директории /var/www/site (ssh/sudo)
это команда которую приходится делать юзеру после внесения изменений в файлы -  chown -R www....
в доме который построил Джек

По целому ряду причин хочется делать это все "локально", например gedit использовать и т.д.
Из тех способов что я могу придумать все кривые:
- редактировать локально, потом scp
- дать 777 на дир (не рассматриваем)
- sftp - опять же... права на папку.

Как ПРАВИЛЬНО добиться того чтобы и апач и user могли нормально читать/писать в www.
Создать группу общую и дать 770/660?  Ну не могу я сообразить

Я конечно могу глупость сказать, немного не понял что нужно, но когда я подымаю локалку для теста своих наработок всегда делаю: sudo chown user_name /var/www - всё работает и локально удобно.

[byebyewin]

Я конечно могу глупость сказать, немного не понял что нужно, но когда я подымаю локалку для теста своих наработок всегда делаю: sudo chown user_name /var/www - всё работает и локально удобно.

ну представь что у тебя проект на удаленном хосте  в процессе перманентного совершенствования и доступ к нему ты имеешь с разных машин, на которых не обязательно поднят локальный вебсервер - т.е. тестировать "результат" необходимо все таки на удаленном хосте.
Доработки все мелкие и делать после каждой chown - можно банально забыть, ну не на крон же вешать)

потому и стоит вопрос - как иметь нормальный доступ на RW для юзера апача (www-data) и юзера твоего (user) без последствий для всего остального.
Типа такого: сел за комп, примаунтил удаленную директорию, редактировал все локально (например в редакторе гуевом каком-то), сохранял попутно все в примаунченную папку, ушел.

[proctoleha]

это директория /var/www/site на удаленном сервере владелец стандартно www-data/www-data

Блин достали уже такие руководства. С какого такого члена апач является владельцем чего-либо? Науя это нужно апачу?
У меня и на локальном хосте (ubuntu server 10.04) и на удаленном (freebsd) все сайты лежат в домашней папке пользователя. Именно он является владельцем DocumentRoot. Все отлично работает. А давать индейцу полные права - это оставлять подарок для юного хакера, который будет ломать ваш сайт.
А насчет удобства для редактирования, в убунте это вообще сказка. Когда сидел на десктопной версии - монтировал удаленный каталог через ssh и вуаля - чем хочешь, тем и редактируй.

[apl]

А если работаешь в CMS? И создаешь файл? То владелец будет www-data
Поэтому права даем 770, а владелец у меня apl:www-data

У меня сделано так
Пользователь решил продолжить мысль 05 Апреля 2011, 19:24:36:Нужно же дать права и CMS, и человеко-юзерам

[proctoleha]

А если работаешь в CMS? И создаешь файл? То владелец будет www-data
Поэтому права даем 770, а владелец у меня apl:www-data

У меня сделано так
Пользователь решил продолжить мысль [time]Tue Apr  5 19:24:36 2011[/time]:Нужно же дать права и CMS, и человеко-юзерам

Если работаешь с CMS, то в руководстве к ней обычно пишут, что на такие то каталоги нужно выставить 777, как правило это temp, image и т.д.
Вот листинг сайта на джумле:

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

%ls -la www/bla-bla-bla/
total 83302
drwxr-x--x  17 olenka  olenka      1024 Mar 18 13:32 .
drwxr-x--x   7 olenka  olenka       512 Mar 19 10:05 ..
-rw-r--r--   1 olenka  olenka      2773 Nov 21 20:43 .htaccess
-rw-r--r--   1 olenka  olenka    102827 Nov 21 20:43 CHANGELOG.php
-rw-r--r--   1 olenka  olenka      1172 Nov 21 20:43 COPYRIGHT.php
-rw-r--r--   1 olenka  olenka     15176 Nov 21 20:43 CREDITS.php
-rw-r--r--   1 olenka  olenka      4344 Nov 21 20:43 INSTALL.php
-rw-r--r--   1 olenka  olenka     17816 Nov 21 20:43 LICENSE.php
-rw-r--r--   1 olenka  olenka     27986 Nov 21 20:43 LICENSES.php
-rw-r--r--   1 olenka  olenka    155333 Nov 26 18:43 Movie1.swf
drwxr-xr-x  11 olenka  olenka       512 Jan 19 08:53 administrator
drwxr-xr-x   7 olenka  olenka       512 Mar 25 23:05 cache
drwxr-xr-x  20 olenka  olenka       512 Jan 19 08:53 components
-rwxr--r--   1 olenka  olenka      2344 Mar  9 15:11 configuration.php
-rw-r--r--   1 olenka  olenka      3411 Nov 21 20:43 configuration.php-dist
-rw-r--r--   1 olenka  olenka        94 Nov 21 20:43 go.php
-rw-r--r--   1 olenka  olenka        53 Nov 23 00:36 google6a7bb1d982945294.html
drwxr-xr-x  10 olenka  olenka      1024 Mar 19 09:50 images
drwxr-xr-x   8 olenka  olenka      1024 Jan 19 08:53 includes
-rw-r--r--   1 olenka  olenka      2049 Nov 21 20:43 index.php
-rw-r--r--   1 olenka  olenka       588 Nov 21 20:43 index2.php
lrwxr-xr-x   1 olenka  olenka         1 Jan 19 08:53 kulagina-olga -> .
drwxr-xr-x   5 olenka  olenka       512 Jan 19 08:53 language
drwxr-xr-x  16 olenka  olenka       512 Jan 19 08:53 libraries
drwxr-xr-x   2 olenka  olenka       512 Jan 19 08:53 logs
drwxr-xr-x   4 olenka  olenka       512 Jan 19 08:53 media
drwxr-xr-x  27 olenka  olenka      1024 Mar 19 12:42 modules
-rw-r--r--   1 olenka  olenka  84822251 Mar 18 13:08 olga.gz
drwxr-xr-x  11 olenka  olenka       512 Jan 19 08:53 plugins
-rw-r--r--   1 olenka  olenka       304 Nov 21 20:43 robots.txt
drwxr-xr-x   7 olenka  olenka       512 Jan 19 08:53 templates
drwxr-xr-x   4 olenka  olenka       512 Mar 19 12:39 tmp
drwxr-x--x   2 olenka  olenka     10240 Apr  5 00:04 webstat
lrwxr-xr-x   1 olenka  olenka         1 Jan 19 08:53 www -> .
drwxr-xr-x   4 olenka  olenka       512 Jan 19 08:53 xmlrpc
-rw-r--r--   1 olenka  olenka         0 Nov 28 11:19 yandex_5dbf4cf2bf4e24e1.txt


Владелец пользователь, не надо индейцу никаких прав, это идеологически неверно.
И на моем сайте, как видите полные права вообще не выставлены, т.к. cms имеет ftp доступ.

[apl]

Я сделал проще - запускаю апачь под своим юзером
Пользователь решил продолжить мысль 05 Апреля 2011, 19:57:12:Я и не говорил, что ко ВСЕМУ нужно поставить полный доступ, но лично я работаю с проектами, когда юзер может заливать/редактировать как через ЦМС, так и по фтп

На рабочих проектах это не принципиально, а вот домашние сайтики...
1. Дома я запускаю апачь под своим юзером
2. CMS ставит по-умолчанию права 755 на создаваемое (если нужны будут другие - изменю конфиг, CMS использую свою собственную и делаю там все что хочу)

Это позволяет мне извращаться как угодно для каких угодно задач,

[byebyewin]

А насчет удобства для редактирования, в убунте это вообще сказка. Когда сидел на десктопной версии - монтировал удаленный каталог через ssh и вуаля - чем хочешь, тем и редактируй.

вот вот вот! именно этого и добиваюсь. Хочу нормальную подсветку синтаксиса, автодополнение и прочие плюшки, а так приходится nano/mcedit еще и комбинации клавиш радикально отличаются. (правоверные линуксоиды ваще сказали бы сразу - учи vim)

это директория /var/www/site на удаленном сервере владелец стандартно www-data/www-data

Блин достали уже такие руководства. С какого такого члена апач является владельцем чего-либо? Науя это нужно апачу?
У меня и на локальном хосте (ubuntu server 10.04) и на удаленном (freebsd) все сайты лежат в домашней папке пользователя. Именно он является владельцем DocumentRoot. Все отлично работает. А давать индейцу полные права - это оставлять подарок для юного хакера, который будет ломать ваш сайт.

Хотел уже было сетовать на то что мол по умолчанию /var/www используется в убунте под веб и ввв-дата его владелец...
щас так подумал, а ведь и правда апачу/энжениксу только чтение надо в основном, а владельцем может быть хоум юзер...
короче буду смотерть в сторону apache2-mpm-itk он вроде бы решает похожие вопросы

Стоп: с другой стороны - пользователь апача имеет доступ только в /var/www ну и в свою папку, а если владельцем будет хоум юзер - теоретически доступ можно получить ко всей системе?
я запутался в общем

[proctoleha]

я запутался в общем

Стоп, давайте по порядку, еще раз.
1. Не надо мудрить, я не знаю что такое apache2-mpm-itk, и т.к. у меня все работает, значит мне это не нужно, и знать пока не хочу.
2. После установки LAMP владельцем папки /var/www по умолчанию является root. И привыкните пожалуйста к мысли, что в линухе права устанавливаются как правило, именно так, как нужно. Движения со стороны пользователей по изменению прав нужны в исключительных случаях, и на определенном этапе. Как показывает практика, права начинают менять или новички, которым все интересно и которые в результате гробят систему, или опытные юзеры, которые отдают себе отчет, что они делают.
3. Если вы собираетесь держать свои хосты в директории  /var/www, то это как раз тот случай, когда необходимо изменить права доступа по умолчанию:

Код: [Выделить]

chown -R username:username /var/wwwВсё! Не надо больше ничего мудрить, вы владелец DocumentRoot, если у вас какая-то CMS, то на отдельные каталоги нужно дать 777. Апач всё прочитает, и все будет прекрасно работать.
4. Если вы решите хранить виртуальные хосты в /home/username, то тем более ничего с правами делать не надо. Прописываете директивы для виртуальных хостов и всё.

Хоум юзер, как вы пишете, имеет доступ только к своему домашнему каталогу! Для доступа ко всей системе нужны права root, но это совсем другая история.

[MA3X]

Из опыта подъема веб-серверов на убунте:
а) запускать апач от юзера, дать юзеру права на /var/www или создать в его хомяке диру www и поместить линк на нее в /var вместо родной www. Хорошо, если юзер один.
б) если юзеров несколько, и нужен доступ по ftp - апач запускается как обычно, то есть от www-data. А юзеров прописываем в proftp так, что у каждого свой логин\пароль, своя дира в /var/www, выше которой он не пойдет(соответствующая его вирт. хосту),  но uid любого такого  юзера == uid www-data.
Тогда все работает.

[byebyewin]

я запутался в общем

Стоп, давайте по порядку, еще раз.

Хоум юзер, как вы пишете, имеет доступ только к своему домашнему каталогу! Для доступа ко всей системе нужны права root, но это совсем другая история.

спасибо за подробные разъяснения. По поводу хоум юзера - я об этом и говорю - sudo дает же возможность получить рутовые права зная пароль пользователя?... не берусь утверждать.
В сети просто куча руководств и все блин разные, сложить более менее правильную картину тяжело, даже вот в этой ветке смотрите:
из учета что веб директория это /var/www
1) Вы говорите: сделать владельцем user, а апачу (www-data) дать права чтения и кое-где 777 - логика я так понимаю в том, что если кто-то ложит/дырявит апач, то в итоге получит лишь доступ на чтение к www дире и вреда нанести не сможет
2) MA3X говорит:  запускать апач от юзера, дать юзеру права на /var/www - тут я так понимаю при ситуации из п1. злоумышленник получит доступ полный к /var/www и /home/user и еще черт знает к чему
3) MA3X говорит:  uid любого такого  юзера == uid www-data - бегло просмотрел по uid инфу, интересно, но надо вникать глубоко.

в итоге, если исходить из задачи описанной в самом первом посте моем - то п.1 как раз  и дает возможность и редактировать файлы в примаунченной удаленно дире  и в то же время не иметь проблем с правами апача. Осталось получить подтверждение что этот способ идеологически верный)

[alexander.pronin]

Если вы решите хранить виртуальные хосты в /home/username, то тем более ничего с правами делать не надо. Прописываете директивы для виртуальных хостов и всё.

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

[proctoleha]

но uid любого такого  юзера == uid www-data.
Тогда все работает.

Хм, дома у меня юзер один, на рабочем хосте несколько, вот листинг:

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

# cat /etc/passwd
# $FreeBSD: src/etc/master.passwd,v 1.40.22.1 2009/08/03 08:13:06 kensmith Exp $
#
root:*:0:0:Charlie &:/root:/bin/csh
toor:*:0:0:Bourne-again Superuser:/root:
daemon:*:1:1:Owner of many system processes:/root:/usr/sbin/nologin
operator:*:2:5:System &:/:/usr/sbin/nologin
bin:*:3:7:Binaries Commands and Source:/:/usr/sbin/nologin
tty:*:4:65533:Tty Sandbox:/:/usr/sbin/nologin
kmem:*:5:65533:KMem Sandbox:/:/usr/sbin/nologin
games:*:7:13:Games pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8:News Subsystem:/:/usr/sbin/nologin
man:*:9:9:Mister Man Pages:/usr/share/man:/usr/sbin/nologin
sshd:*:22:22:Secure Shell Daemon:/var/empty:/usr/sbin/nologin
smmsp:*:25:25:Sendmail Submission User:/var/spool/clientmqueue:/usr/sbin/nologin
mailnull:*:26:26:Sendmail Default User:/var/spool/mqueue:/usr/sbin/nologin
bind:*:53:53:Bind Sandbox:/:/usr/sbin/nologin
proxy:*:62:62:Packet Filter pseudo-user:/nonexistent:/usr/sbin/nologin
_pflogd:*:64:64:pflogd privsep user:/var/empty:/usr/sbin/nologin
_dhcp:*:65:65:dhcp programs:/var/empty:/usr/sbin/nologin
uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/local/libexec/uucp/uucico
pop:*:68:6:Post Office Owner:/nonexistent:/usr/sbin/nologin
www:*:80:80:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
nobody:*:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin
mysql:*:88:88:MySQL Daemon:/nonexistent:/sbin/nologin
pgsql:*:70:70:PostgreSQL Daemon:/usr/local/pgsql:/bin/sh
dovecot:*:143:143:Dovecot User:/var/empty:/usr/sbin/nologin
cyrus:*:60:60:the cyrus mail server:/nonexistent:/usr/sbin/nologin
postgrey:*:225:225:Postgrey Owner:/var/db/postgrey:/sbin/nologin
bla-bla-bla:*:1000:1002:bla-bla-bla:/home/bla-bla-bla/data:/bin/csh
bla-bla-bla:*:1001:1003:bla-bla-bla:/home/bla-bla-bla/data:/bin/csh
bla-bla-bla:*:1002:1004:bla-bla-bla:/home/bla-bla-bla/data:/bin/csh

И где тут одинаковый uuid для пользователя и www? У каждого юзера свой домашний каталог, когда я захожу через ftp - я попадаю только туда, куда мне разрешено. У индейца права только на чтение. Все прекрасно работает. И абсолютно фиолетово, что дома у меня ubuntu server, на удаленном хосте фряха. Линукс он и в Африке Линукс, основы везде одинаковы.

[byebyewin]

Если вы решите хранить виртуальные хосты в /home/username, то тем более ничего с правами делать не надо. Прописываете директивы для виртуальных хостов и всё.

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

я когда винт размечал при установке, исходил из чтения руководств.. разных, но выбирал вроде популярные, так вот там речь шла про /var/www и соответственно под нее я отвел большую часть пространства.

Кстати вот пример того с чем прийдется мириться при установке владельцем хоум юзера:

Установите права на запись в директорию config
Установите права на запись в директорию tools
Установите права на запись в директорию cache
Установите права на запись в файл sitemap.xml
Установите права на запись в директорию img и поддиректории
Установите права на запись в директорию mails и поддиректории
Установите права на запись в директорию modules и поддиректории
Установите права на запись в директорию themes/lang/ рекурсивно
Установите права на запись в директорию translations и поддиректории
Установите права на запись в директорию upload и поддиректории
Установите права на запись в директорию download и поддиректории

т.е. теперь прийдется на эти пути давать запись "для всех"? или идти по пути "запускать апач от user"?

[apl]

У меня сайты весят ~100 гигов, я не стал их держать на одном разделе с / и вынес в /media/www