Який найкращий спосіб обробки дозволів для www-даних Apache 2 користувача в / var / www?

Хтось отримав гарне рішення для обробки файлів /var/www? Ми працюємо з віртуальними хостами на основі імен, а користувач Apache 2 - це www-data .

У нас є два постійні користувачі & root. Тож коли возитися з файлами /var/www, а не треба ...

chown -R www-data:www-data

... весь час, який хороший спосіб впоратися з цим?

Додаткове запитання: наскільки хардкор ви потім отримуєте дозволи?

Це завжди було проблемою в умовах спільної розробки.

Спроба розширити @ Zoredache в відповідь , так як я даю це піти собі:

• Створіть нову групу (www-pub) та додайте користувачів до цієї групи

  groupadd www-pub

  usermod -a -G www-pub usera ## повинен використовувати -a для додавання до існуючих груп

  usermod -a -G www-pub userb

  groups usera ## групи відображення для користувача

• Змініть право власності на все під / var / www на root: www-pub

  chown -R root:www-pub /var/www ## -R для рекурсивного

• Змініть дозволи всіх папок на 2775

  chmod 2775 /var/www ## 2 = встановити ідентифікатор групи, 7 = rwx для власника (root), 7 = rwx для групи (www-pub), 5 = rx для світу (включаючи апаш www-data user)

  Біт встановлення ідентифікатора групи ( SETGID ) (2) призводить до копіювання групи (www-pub) у всі нові файли / папки, створені у цій папці. Інші параметри - SETUID (4) для копіювання ідентифікатора користувача та STICKY (1), який, на мій погляд, дозволяє лише власнику видаляти файли.

  Існує -Rрекурсивна опція, але це не буде розрізняти файли та папки, тому вам доведеться використовувати find , як-от так:

  find /var/www -type d -exec chmod 2775 {} +

• Змініть всі файли на 0664

  find /var/www -type f -exec chmod 0664 {} +

• Змініть umask для своїх користувачів на 0002

  Umask керує дозволами на створення файлів за замовчуванням, 0002 означає, що файли матимуть 664, а каталоги 775. Якщо встановити це (редагуючи umaskрядок внизу /etc/profileв моєму випадку) означає, що файли, створені одним користувачем, можуть записуватися іншими користувачами в www- групувати, не потребуючи chmodїх.

Перевірте все це, створивши файл і каталог та підтвердивши власника, групу та дозволи ls -l.

Примітка. Вам потрібно буде ввійти / увійти, щоб зміни в ваших групах набули чинності!

Я не зовсім впевнений, як ви хочете налаштувати дозволи, але це може дати вам вихідну точку. Можливо, є кращі способи. Я припускаю, що ви хочете, щоб обидва користувачі могли змінити що-небудь під / var / www /

• Створіть нову групу (www-pub) та додайте користувачів до цієї групи.
• Змініть право власності на все під / var / www на root: www-pub.
• Змініть дозволи всіх папок на 2775
• Змініть всі файли на 0664.
• Змініть umask для своїх користувачів на 0002

Це означає, що будь-який новий файл, створений будь-яким з ваших користувачів, повинен мати ім’я користувача: www-pub 0664, і будь-який створений каталог буде ім'ям користувача: www-pub 2775. Apache отримає доступ для читання до всього через компонент "інших користувачів". Біт SETGID у каталогах змусить усіх створених файлів належати групі, якій належить папка. Налаштування umask потрібно, щоб переконатися, що біт запису встановлений так, що будь-хто з групи зможе редагувати файли.

Щодо того, наскільки хардкор я продовжую отримувати дозволи. Це повністю залежить від сайту / сервера. Якщо є лише 1-2 редактори, і мені просто потрібно, щоб вони не надто сильно ламали речі, тоді я пройду легко. Якби бізнес вимагав чогось складнішого, тоді я створив би щось складніше.

Я думаю, що ви можете виявити POSIX ACL (списки контролю доступу) як корисні. Вони дозволяють тонкозернисту модель дозволів порівняно з користувачем: group: other model. Я виявив, що їх простіше тримати прямо в моїй голові, оскільки я можу бути більш чітким, а також можу встановити поведінку "за замовчуванням" для гілки файлової системи.

Наприклад, ви можете чітко вказати дозволи кожного користувача:

setfacl -Rm d:u:userA:rwX,u:userA:rwX /var/www
setfacl -Rm d:u:userB:rwX,u:userB:rwX /var/www

Або ви можете зробити це на основі деякої спільної групи:

setfacl -Rm d:g:groupA:rwX,u:groupA:rwX /var/www

І, можливо, ви хочете зберегти свого користувача Apache лише для читання

setfacl -Rm d:u:www-data:rX,u:www-data:rX /var/www

Сторінки чоловіка:

• setfacl
• getfacl

Навчальний посібник

Це питання було задано ще раз , і, як обговорювалося на мета, поточна найкраща практика забезпечує кращі підходи, ніж це було в 2009 році, коли це було задано. Ця відповідь намагається дати деякі сучасні рішення для безпечного поводження з спільними веб-розробниками .

Для безпечного веб-сервера та спільної розробки існує більше, ніж лише дозволи на використання файлів:

• Майте окремого користувача для кожного сайту, тобто не обслуговуйте всі сайти, які використовують www-data. Це важливо, оскільки сьогодні Apache рідко обслуговує виключно статичні файли вмісту, але працює з динамічними веб-сайтами. Ця відповідь зосереджена на PHP, оскільки це найпоширеніша мова серверного сайту, але ті ж принципи застосовуються і до інших.

  Якщо у вас є проблеми із безпекою на одному веб-сайті, він може поширюватися на кожен сайт, який працює як один і той же користувач. Зловмисник може бачити все, що бачить користувач, включаючи інформацію для входу в базу даних, і змінювати всі сайти, на які користувач має права на запис.

• Використовуйте протокол передачі файлів SSH (SFTP). Хоча від використання FTP слід відмовитися від безпеки (оскільки він надсилає і паролі, і вміст у простому тексті), безпечний замінник SFTP також має функцію, яка є ідеальним рішенням для спільної веб-розробки.

  Виділивши сайти та одного користувача на кожен сайт, вам потрібно надати доступ своїм веб-розробникам, про що йдеться у цьому питанні. Замість того, щоб надати їм паролі для цих користувачів сайту - або отримати доступ до файлів сайту, використовуючи їх особисті облікові записи, як було запропоновано, - ви можете використовувати SSH-ключі для входу.

  Кожен розробник може створити ключ та зберегти секретний ключ в секреті. Потім відкритий ключ додається у ~/.ssh/authorized_keysфайл для кожного облікового запису користувача веб-сайту, над яким працює розробник. Це має багато переваг для керування паролями та входами:

  • Кожен розробник може мати доступ до будь-якої кількості веб-сайтів без тягаря запам'ятовувати або зберігати всі паролі, пов’язані з домовленістю користувача на сайт.

  • Не потрібно змінювати та ділитися паролями щоразу, коли хтось залишає компанію.

  • Ви можете використовувати дуже міцні паролі або взагалі відключити вхід на основі пароля.

• Використовуйте PHP-FPM . Це сучасний підхід для запуску PHP як користувача. Створіть новий пул для кожного користувача, тобто один пул на кожен сайт. Це найкраще як для безпеки, так і для продуктивності, оскільки ви також можете вказати, скільки ресурсів може використовувати один сайт.

  Дивись , наприклад , NeverEndingSecurity в Run PHP-FPM з одним користувачем / UID і групи по Linux . Існують навчальні посібники на зразок HowtoForge's Використання PHP-FPM з Apache на Ubuntu 16.04 , який не використовує PHP-FPM для підвищення безпеки через розділення користувачів, вказуючи на використання одного сокета FPM на сервері.