web-dev-qa-db-ja.com

ファイルを所有していないがディレクトリへの書き込み権限を持っている場合にUnixの権限を変更するにはどうすればよいですか？

私は同僚とgitリポジトリを共有していますが、gitはUnixファイルのパーミッションの全容を伝播しないため、更新時に実行される「フック」があり、必要に応じて「その他」のパーミッションを設定します。問題？フックはchmodを使用しますが、同僚がファイルをコミットすると、彼がそのファイルを所有しているため、そのファイルでchmodを実行できません。その逆も同様です。ディレクトリはすべてグループ書き込み可能でスティッキーなので、私たちのどちらかがファイルを削除して、同じ名前、同じ内容、異なる所有権のファイルに置き換える権利があると思います。おそらく、それをchmodすることができます。しかし、これはひどく大きなハンマーのように思えます、そして私はそれを台無しにするのに少し不安です。したがって、2つの質問：

  1. 誰かがそれを行う別の方法を考えることができますか？

  2. そうでない場合、「このファイルを自分のものにする」を実装するbulletproofシェルスクリプトの最適な設計は何ですか？ファイルシステム間の移動などはありません。

気付いていないかもしれない人のために、書き込み許可はchmodに許可を与えません：

% ls -l value.c
-rw-rw---- 1 agallant ta105 133 Feb 10 13:37 value.c
% [ -w value.c ] && echo writeable
writeable
% chmod o+r value.c               
chmod: changing permissions of `value.c': Operation not permitted

私たちは両方ともta105グループ。

ノート：

  1. gitを使用して、変更を調整するだけでなく、リポジトリをコースWebサイトとして公開しています。 Webサイトの公開は、リポジトリの主な目的です。パーミッションスクリプトは、gitフックを使用して更新のたびに実行され、学生がまだ公開されていないソリューションを読み取るパーミッションを持たないようにします。

  2. 私が間違ったumaskを持っていることを示唆しないでください。リポジトリ内のすべてのファイルが同じアクセス許可を持つ必要はありません。どのumaskを選択しても、一部のファイルのアクセス許可を変更する必要があります。言うまでもなく、同僚にumaskの設定を課すことは私にとって無礼です。

  3. [〜＃〜] update [〜＃〜]：私たちの環境では、アクセスできるすべてのマシンでrootがnobodyに押しつぶされていることを知りました。そのため、 root権限に依存するソリューションは機能しません。

shellunixfile-permissions
18
Norman Ramsey

これを行う最も簡単な方法は、パートナーとあなたを新しいグループ（たとえば、「開発」）のメンバーにして、それをファイルのグループにすることです。そうすれば、どちらかが所有でき、グループが正しい限り、両方で作業できます。

それがうまくいかない場合は、「Sudo」を構成して、その2人のユーザーだけがパスワードなしでrootとしてその特定のディレクトリ内のファイルに対してchmodコマンドを実行できるようにすることができます。

3
dj_segfault

umask を正しく設定すると、最初に正しい権限でファイルを作成できます。

$ umask 0022
$ touch foo
$ ls -l foo
-rw-r--r-- 1 sarnold sarnold 0 2011-02-20 21:17 foo
$ rm foo
$ umask 0002
$ touch foo
$ ls -l foo
-rw-rw-r-- 1 sarnold sarnold 0 2011-02-20 21:17 foo
2
sarnold

おそらく最もエレガントな方法ではありませんが、うまくいくようです

$ umask 0002
$ mv value.c value.c.tmp
$ cat value.c.tmp > value.c
$ rm value.c.tmp

防弾にすることができると主張する人もいるかもしれませんが、誰かがRPGを持ってきます...

bothの両方がchmodする必要がある場合、別の方法を考えることはできません-それでよければ[〜＃〜] you [ 〜＃〜]chmodできますが、他の人はできません、chmod 6770 .またはchmod g+s,u+s .ディレクトリ内（たとえば、SUIDとGUIDビットを設定））なので、ディレクトリを所有するものが常にファイルの所有者になります。残念ながら、一部（ほとんどではないにしても）、つまりEXT2/3/4SUIDビットを無視します。

もちろん、umaskを0002に設定すると、必須にしないことで問題が解決します。

0
Kimvais

私は一歩後退しています。まだ読んでいないシステムの制限に違反している場合はお知らせください。

あなたの質問から、file:// URLを使用してgitリポジトリを共有しようとしていて、承認などを処理するためにUNIXファイルシステムのアクセス許可に依存していると思います。リポジトリを共有する別の方法を検討してみませんか。この面倒なことはしませんか？

私は2つの方法を考えることができます。

  • どちらのマシンにもベアリポジトリを作成し、それをリモートとして作業リポジトリに追加して、それを使用して共同作業を行うことができます。提供は、組み込みのgit daemonコマンドを使用して実行できます。詳細は ここ です。ただし、これではアクセス制御はできません。
  • gitosis をローカルにインストールし、それを使用してリポジトリにサービスを提供できます。これにより、単純なアクセス制御システムが可能になり、特定のユーザーを制限/許可できます。

少し前に出てきた、関連するかもしれない関連する質問がありました。 git daemonは彼のために働いた--- root権限なしでgitリポジトリを管理する

また、サーバーの障害で、問題に関連する可能性のあるものが見つかりました https://serverfault.com/questions/21126/git-daemon-and-access-control-for-multiple-repos

0
Noufal Ibrahim

公開フックが実際にファイルをデプロイすると仮定すると、作業コピーでパーミッションを設定するだけでなく、一時的な場所にデプロイしてから、rsyncを使用してファイルの内容とパーミッションが正しいことを確認できます。

少し良いですが、私が推測しているインフラストラクチャが必要な場合は、デプロイスクリプトが1人のユーザーの下でのみ実行されるようにする必要があります。これは、システム管理者が許可する場合はSudoを使用するか、gerritなどのgitサーバーサービスを設定するか、5分ごとにcronジョブを実行して更新を確認し、必要に応じてデプロイすることで実行できます。

0
Andrew Aylett

わかりました、以前の回答に基づいて構築されたものの混合：

  • fstabにマウントすれば、フォルダのumaskを設定できます。そのマウントで作業する人々に同意できれば、g + wを強制できます

  • そのフォルダのgroup-idビット（g + s）を設定すると、すべてのファイルがそのフォルダが属するグループに属するため、ファイルのグループ所有権が伝播されます

それは実行可能ですか？もちろん、そのマウントポイントを強制することは簡単な作業ではありません。その周りのより良いアイデアは誰ですか？

0
Miquel

これはうまくいくかもしれません：

touch $name.tmp
chmod 660 $name.tmp
cp $name $name.tmp
if cmp $name $name.tmp 2>/dev/null; then
    rm $name && \
        cp $name.tmp $name && \
        rm $name.tmp
fi

それはあなたの元のアイデアの単なるバリエーションです

0
bluesmoon