В первую очередь я пытаюсь установить разрешения внутри / var / www. Мы используем формат проекта, который имеет следующую общую для каждого проекта структуру:
В настоящее время:
Я могу добиться того, чтобы это работало достаточно честно, но я совершенно уверен, что делаю это неправильно. Слишком много 755-х; и я плохо разбираюсь в липких битах, которые я собираюсь погуглить глубже.
На серверах разработки основная часть должна принадлежать nginx: dev, где nginx также входит в группу разработчиков. на постановке это nginx: admin, на постановке - nginx: appupdater
Моя главная цель сегодня заключается в том, чтобы у группы разработчиков была возможность создавать и редактировать любые файлы в каталоге проекта (project.com, site.com, ...), в то время как каталог / shared должен иметь только обновляться вручную очень редко.
Во-первых, я бы хотел установить такие разрешения, чтобы новые файлы принадлежали nginx: разработчики и разработчики могли свободно загружать и изменять их на сервере разработки. Я пытаюсь получить разрешения лучше всего при запрещении доступа везде, где это возможно, позволяя приложениям, работающим (как nginx), загружать файлы из каталогов поддержки и приложений. Единственное исключение - необходимость записи в / static / upload и папки в / support / created
Как я могу защитить это разрешение, чтобы мы могли запускать приложения, позволять разработчикам получать доступ и создавать файлы без переопределения группы owner: и, как правило, не стрелять себе в ногу, если пользователь загружает исполняемые файлы?
(помимо проверки приложения / сервера для меня)
Давным-давно я пришел к выводу, что лучший способ поделиться веб-проектом между группой пользователей - это заставить их использовать sudo или ssh чтобы всегда входить в систему как один пользователь-разработчик, используемый для всех файлов проекта. Если вам нужно отслеживать изменения, внесенные отдельными разработчиками, лучше позволить им работать в их собственных средах, и вышесказанное будет применяться к релизной инженерии, а не к разработчикам.
С участием sudo вы можете предоставить разрешения для доступа пользователя к системной группе, а затем добавить пользователей в группу. С участием ssh вам нужно добавить пользовательские SSH-ключи непосредственно пользователю разработчика .ssh/authorized_keys.
До этого я пробовал много техник с использованием разрешений и списков ACL-списков posix, но они оказались бесполезными. В частности, установка бита выполнения в файле зарезервирована для владельца, поэтому я предпочитаю, чтобы все пользователи переключились на UID владельца, прежде чем вносить какие-либо изменения.
У них также есть представление о проекте, над которым они работают, и о домашнем каталоге, поэтому поддерживать общие ресурсы намного проще.
Затем приложение может работать под другим пользователем (возможно, в той же группе), который имеет доступ только для чтения к данным, за исключением упомянутых вами каталогов. В более или менее однопользовательской среде вам не понадобится липкий бит. Он предназначен для защиты файлов в tmp справочники от не владельцев.
Теоретическим решением является использование мощной системы ACL, такой как ACL NFSv4, но встроенная поддержка для этого обычно недоступна. Есть патчи, но вы, вероятно, не захотите тратить на это время и, наконец, получите более сложное решение, чем то, которое я описал выше.