Coda 2 и SCP загружают файлы с неверным разрешением
4576
Tom Black
В настоящее время у меня есть базовый сервер Ubuntu, на котором работает веб-сайт. Веб-сайт предназначен для нескольких студентов, изучающих HTML / PHP, и каждый студент имеет свою учетную запись с символической ссылкой на общую папку на веб-сайте. Поскольку студенты работают на веб-сайте вместе, каждый пользователь должен иметь возможность изменять все файлы (например, index.html). Поэтому я создал группу Webdev, содержащую всех студентов с установленным по умолчанию значением umask 0002 в их .bashrc (это позволяет вновь создаваемым файлам иметь 774). Общая папка принадлежит группе Webdev с помощью chmod g + s, поэтому новые файлы / папки также принадлежат группе Webdev.
Проблема заключается в том, что учащиеся используют IDE (Coda 2), и когда они создают новый файл или папку с помощью IDE, файл имеет разрешения 644 на сервере (не для записи в группе). Однако, когда я создаю новый файл через соединение с Cyberduck (клиент SFTP), права доступа к файлу равны 664 (как и должно быть). Так что я не понимаю, почему Coda была бы другой.
Однако после некоторых проб и ошибок я считаю, что Coda сначала создает файл на локальном диске, а затем загружает этот файл на сервер. На Mac по умолчанию вновь создан файл 644. Когда клиент загружает файл, который уже 644, он остается 644 на стороне сервера (в этой ситуации umask отчасти бесполезен). Я также пытался создать разрешения ACL для этой папки, но загруженный файл с моего Mac через SCP не получает разрешения ACL по умолчанию.
В Coda есть возможность изменить права доступа к файлу при передаче. Однако эта опция, кажется, применяет chmod ко всем загружаемым или сохраненным файлам. Когда один из студентов изменяет файл, созданный кем-то другим, когда он пытается загрузить файл или сохранить его, Coda также пытается выполнить chmod, но не удается, потому что этот пользователь не является владельцем файла.
Мое текущее решение - использовать bindfs ... Я подключаю общую веб-папку, а bindfs устанавливает разрешения и групповую собственность вновь создаваемых файлов. Однако bindfs кажется немного медленным, и я уверен, что есть лучшее решение.
Даже если студенты отказались от Coda 2 и использовали Mac vim с scp, вновь созданные файлы на сервере вели бы себя так же (644), что по умолчанию на mac.
Другие опции...
1) Либо я учу студентов использовать (ssh / chmod) вместе со своей IDE для изменения собственных прав доступа к файлам при загрузке.
2) Я установил на всех компьютерах Маки umask по умолчанию 0002, который бы загружал файлы с нужными разрешениями.
3) Напишите скрипт кукурузы для исправления прав доступа к файлам каждые 5–15 минут ... (Этот вариант, я думаю, является наихудшим, если студенты работают вместе).
Можно ли как-нибудь сделать так, чтобы все файлы, загружаемые через SCP, имели разрешения по умолчанию для файлов 664, даже если загруженный файл имеет более низкие разрешения? (После нескольких часов поиска я не думаю, что это возможно). Я полагаю, что кукурузный скрипт - мой лучший вариант для начинающих пользователей. Как веб-разработчики работают вместе на больших сайтах?
Coda actually uploads local files. Unless you use hacks like the now unsupported/outdated http://sftpfilecontrol.sourceforge.net, the files will have whatever permissions they have locally. Since OSX has umask 022, files created on OSX are not group writable, so 644. Coda happily uploads that. As you found out, Coda can force specific permissions, but it isn't fine grained enough to specify it should only be done for new files, so it will error on saving existing files that aren't owned by the user (which is the most common case). The only way I got this to work, is by changing the users umask on OSX. Create the file /etc/launchd-user.conf and put in there:
umask 002
Then reboot. Afterwards, Coda creates files that are 664 locally, and uploads them. Files are now properly group writeable, and there is no need for the Set permissions on upload option in the Coda prefs.
In the Coda preferences panel, under the Rules tab, it looks like you can set the desired permissions for files uploaded via ftp/sftp. The default is 644; looks like just checking the "Write" box in the "Group" line could fix the problem. Each student would have to do this in their own copy of Coda, of course.
Я говорил об этом в своем посте ... Coda, кажется, применяет chmod ко всем файлам, которые сохранены / загружены. Если учащийся изменяет файл, который ему / ей не принадлежит, Coda возвращает большую жирную ошибку. Точная ошибка: «Убедитесь, что у вас есть разрешение на изменение этого файла. Этот сервер или файл может не позволять вам изменять разрешения. Дважды проверьте, правильно ли установлены ваши разрешения в настройках Правил».
Tom Black 11 лет назад
0
1
Richard Milewski
The problem is not the permissions on the file, but the group(s) to which your students belong. On the web server machine, if you make each student's primary group the same as web-server's group (on Linux systems usually www-data or apache), and set the Default File permissions to 660 in the Coda prefs pane, all should be well.
# usermod -g apache studentUID
or
# usermod -g www-data studentUID
depending upon which flavor of Linux you're running on the web server.