Як я можу надавати файлам та каталогів, створеним FTP, правильні дозволи для Apache для їх читання та запису?


8

Я більше людина в ОС Windows, тому, вибачте, будь ласка, моє незнання з цим основним питанням Linux.

Я доглядаю за сервером Linux (Debian), на якому встановлені лише Apache2 та vsftp.

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

Це моє розуміння поки що:

  • Користувачеві www-data потрібна власність на папки та файли, оскільки всі файли в / var / www / html запускають сценарії, які вимагають, щоб вони писали у свою папку. І, звичайно, потрібно мати можливість обслуговувати сторінки за допомогою http.
  • Мій ftp-користувач (дозволяє називати його ftpuser ) також вимагає дозволу на запис у папку / var / www / html (рекурсивна), оскільки мені потрібно мати можливість завантажувати нові файли.

Зважаючи на це, я створив групу під назвою ftpandwww і порушив усі папки та файли цієї групи. Це працювало до певної міри ...

Я майже в потрібному місці, за винятком того, що будь-які нові папки, створені за допомогою мого FTP-клієнта, мають неправильні дозволи (що я можу виправити, змінивши їх під FTP-клієнтом), але потім www-data не можуть записати на них тому що вони є власником ftpuser, і я в кінцевому підсумку мушу в SSH запустити хауна до ftpandwww групи, щоб вони були обоє щасливі.

Як зробити всі нові папки, які я створюю під FTP, мають правильні дозволи (774) і автоматично належать групі ftpandwww, яку я можу завантажувати та обслуговувати через Інтернет (з дозволом на запис), не входячи і не затримуючи всі нові папки та файли кожного разу?


Відповіді:


10

Використовуйте дозволи SetGID у веб-корінному каталозі та розповсюджуйте їх дітям.

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

Щоб застосувати SetGID до об'єкта файлової системи, використовуйте значення chmod2 перед кодом дозволу.
(наприклад: 740 => 2740).

Я використовую SetGID на багатьох своїх спільних акціях Samba, так що у файлах завжди є група власників, Usersі будь-який член групи може читати файли (я зазвичай використовую 2750так, що у файл може писати лише власник користувача).

У вашому випадку запустіть щось подібне (замініть XXX на потрібні дозволи):

sudo chown -R  root:ftpandwww /var/www
sudo chmod -R 2XXX /var/www 

Тоді нові файли та папки вийдуть на зразок права власності ftpuser:ftpandwww.

Редагувати:

Залежно від вашої корисної справи, SetGID, ймовірно, достатньо, щоб вирішити вашу проблему, але якщо у вас виникають проблеми, у яких одному чи іншому користувачеві заборонено писати, через неправильний груповий дозвіл (але право власності є правильним), то найкраще встановити свою ставку звичай UMASK для користувача , який створює файли .

Якщо у вас виникли труднощі з налаштуванням UMASK для користувача (оскільки це демон), перевірте цю тему щодо параметрів налаштування UMASK користувача демона .

Я б рекомендував маску, 007якщо ви хочете, щоб члени групи мали змогу писати та видаляти файли та не мати пільг для власників.


Дякую, я спробую це, коли ви згадаєте, що всі файли та папки матимуть це право власності ftpuser: ftpandwww буде www-дані все ще обслуговувати їх і матимуть дозволи (через скрипт) також писати назад у папки? Знову дякую.
omega1

Фактичним власником-користувачем, ймовірно, буде той користувач, який здійснює процес, якщо тільки він не використовує локальну аутентифікацію (але це повністю залежить від програми). У будь-якому випадку відповідь на ваше запитання залежить від XXX, який ви вибрали. оскільки і wwwdata, і ftpdata в одній групі, якщо ви дасте 770, то так, обидва рахунки зможуть записувати в об’єкти. якби ви дали йому 740, проте, лише власник-користувач міг би писати, але будь-який член ftpandwww міг би читати. Сенс у тому, що для цих операцій ви використовуєте групові perms, а не perms для користувачів.
Френк Томас
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.