web-dev-qa-db-ja.com

Coda2とSCPが間違った権限でファイルをアップロードしている

現在、私はWebサイトを実行している基本的なUbuntuサーバーを持っています。このWebサイトは、HTML/PHPを学習する数人の学生向けであり、各学生は、共有Webサイトフォルダーへのシンボリックリンクを持つ独自のアカウントを持っています。学生は一緒にWebサイトで作業しているため、各ユーザーはすべてのファイル(index.htmlなど)を変更できる必要があります。そこで、.bashrcにデフォルトのumaskが0002に設定された、すべての学生を含むWebdevグループを作成しました(これにより、新しく作成されたファイルを774にすることができます)。共有フォルダーは、chmod g + sを持つグループWebdevによって所有されているため、新しいファイル/フォルダーもグループWebdevに属します。

問題は、学生がIDE(Coda 2)を使用していて、IDEを使用して新しいファイルまたはフォルダーを作成するとき、ファイルには次の権限があります。サーバー上で644(グループ書き込み不可)。ただし、Cyber​​duck(SFTPクライアント)に接続して新しいファイルを作成すると、ファイルのアクセス許可は664になります(本来あるべき姿です)。したがって、Codaが異なる理由がわかりません。

ただし、試行錯誤の末、Codaは最初にローカルディスクにファイルを作成し、次にそのファイルをサーバーにアップロードしていると思います。 Macでは、デフォルトで新しく作成されたファイルは644です。クライアントがすでに644であるファイルをアップロードすると、サーバー側に644のままになります(この状況では、umaskは一種の役に立たない)。そのフォルダのACL権限も作成しようとしましたが、MacからSCP経由でアップロードされたファイルにデフォルトのACL権限がありません。

Codaには、転送時にファイルのアクセス許可を変更するオプションがあります。ただし、このオプションは、アップロードまたは保存されるすべてのファイルにchmodを適用するようです。学生の1人がファイルをアップロードまたは保存しようとしたときに他の誰かが作成したファイルを変更している場合、Codaはchmodも実行しようとしますが、そのユーザーがファイルの所有者ではないため失敗します。

私の現在の解決策はbindfsを使用しています...共有Webフォルダーをマウントし、bindfsは新しく作成されたファイルのアクセス許可とグループ所有権を設定します。ただし、bindfsは少し遅いようで、より良い解決策があると確信しています。

学生がCoda2を捨て、scpでMac vimを使用したとしても、サーバー上に新しく作成されたファイルは、Macのデフォルトと同じように動作します(644)。

別のオプション...

1)アップロード時に自分のファイル権限を変更するためにIDE)で(ssh/chmod)を使用するように生徒に教えます。

2)すべての学生のMacにデフォルトのumaskである0002を設定します。これにより、適切な権限でファイルがアップロードされます。

3)5〜15分ごとにファイルのアクセス許可を修正するコーンスクリプトを作成します...(このオプションは、学生が同時に作業している場合は最悪だと思います)。

アップロードされたファイルのアクセス許可が低い場合でも、SCPを介してアップロードされたすべてのファイルにデフォルトのファイルアクセス許可である664を設定する方法はありますか? (何時間も検索した後、これは不可能だと思います)初心者ユーザーにとってはトウモロコシのスクリプトが私の最善の選択肢だと思います。 Web開発者はより大きなサイトでどのように協力しますか?

これに似ています: https://serverfault.com/questions/283492/how-to-specify-file-permission-when-putting-a-file-using-openssh-sftp-command

同様に: https://serverfault.com/questions/395418/managing-linux-directory-permissions-sftp

3
Tom Black

Codaは実際にローカルファイルをアップロードします。現在サポートされていない/時代遅れの http://sftpfilecontrol.sourceforge.net のようなハックを使用しない限り、ファイルにはローカルでのアクセス許可があります。 OSXにはumask022があるため、OSXで作成されたファイルはグループ書き込み可能ではないため、644です。Codaはそれを喜んでアップロードします。ご存知のように、Codaは特定のアクセス許可を強制できますが、新しいファイルに対してのみ実行するように指定するのに十分な粒度ではないため、ユーザーが所有していない既存のファイルを保存するとエラーが発生します(これは最も一般的なケース)。これを機能させる唯一の方法は、OSXでユーザーのumaskを変更することです。ファイルを作成します/etc/launchd-user.confそしてそこに入れます:

umask 002

その後、再起動します。その後、Codaはローカルで664のファイルを作成し、それらをアップロードします。ファイルは適切にグループ書き込み可能になり、Coda設定でアップロード時にアクセス許可を設定するオプションは必要ありません。

http://support.Apple.com/kb/HT2202 も参照してください。

3
Dick Visser

Coda設定パネルの[ルール]タブで、ftp/sftp経由でアップロードされたファイルに必要なアクセス許可を設定できるようです。デフォルトは644です。 「グループ」行の「書き込み」ボックスをチェックするだけで問題が解決するようです。もちろん、各学生は自分のCodaのコピーでこれを行う必要があります。

1
chepner

問題はファイルの権限ではなく、生徒が所属するグループです。 Webサーバーマシンで、各学生のプライマリグループをWebサーバーのグループと同じにし(Linuxシステムでは通常www-dataまたはApache)、Coda設定ペインでデフォルトファイルのアクセス許可を660に設定すると、すべてうまくいくはずです。 。

# usermod -g Apache studentUID

または

# usermod -g www-data studentUID

webサーバーで実行しているLinuxのフレーバーによって異なります。

1