権限が大丈夫ですが、シンボリックリンクを新しいターゲットに更新するときに権限が拒否されるのはなぜですか?

権限が大丈夫ですが、シンボリックリンクを新しいターゲットに更新するときに権限が拒否されるのはなぜですか?

Linuxシステム(実際にはコンピューティングクラスタ)から他のユーザーのフォルダをコピーしました(彼は私に適切なchmodを使ってこれを行う権限を与えました)。

フォルダには、アクセスできないファイルへのシンボリックリンクが含まれています。私が持っているのと同じファイルのコピーを指すように更新したいと思います。

しかし、私がln -sfこれをPermission denied使用しようとしたとき

なぜこれが起こるのですか?

リンクは次のとおりです。

$ ls -l 50ATC_Rep2.fastq
lrwxrwxrwx 1 bli cifs-BioIT 55 21 nov.  13:45 50ATC_Rep2.fastq -> /pasteur/homes/mmazzuol/Raw_data/CHIP_TEST/BM50.2.fastq

ターゲットにアクセスすることはできませんが、コピーがあります。これは私が新しい目標について欲しいものです:

$ ls -l ../../../raw_data/CHIP_TEST/BM50.2.fastq
-rwxr-xr-x 1 bli cifs-BioIT 4872660831 21 nov.  14:00 ../../../raw_data/CHIP_TEST/BM50.2.fastq

私が試してみると、これが起こりますln -sf

$ ln -sf ../../../raw_data/CHIP_TEST/BM50.2.fastq 50ATC_Rep2.fastq
ln: accessing `50ATC_Rep2.fastq': Permission denied

リンク自体の権限ではなく、現在の宛先の権限が重要なようです。

最初にリンクを削除してから再作成すると、問題を回避できます。

$ rm 50ATC_Rep2.fastq
rm: remove symbolic link `50ATC_Rep2.fastq'? y
$ ln -s ../../../raw_data/CHIP_TEST/BM50.2.fastq 50ATC_Rep2.fastq
$ ls -l 50ATC_Rep2.fastq
lrwxrwxrwx 1 bli cifs-BioIT 40 21 nov.  18:57 50ATC_Rep2.fastq -> ../../../raw_data/CHIP_TEST/BM50.2.fastq

リンクを削除できますが、更新できないのはなぜですか?

答え1

lnLinuxではGNU実装が使用されているようです。stat()関数はターゲットが存在するかどうかを決定します。この関数はシンボリックリンクの検証を必要とするため、既存のリンクの宛先にアクセスできない場合、関数はEACCESS(「許可拒否」)を返し、ユーティリティは失敗します。これはstraceUbuntu Linuxシステムで確認されました。

GNUをln使うlstat()代わりにシンボリックリンクをチェックせず、-n(非標準)オプション(GNUが--no-dereferenceエイリアスとしてさらに使用する-n)を使用して呼び出す必要があります。

ln -s -n -f ../../../raw_data/CHIP_TEST/BM50.2.fastq 50ATC_Rep2.fastq

読書POSIX仕様ln、仕様で定義されていない、または指定されていないいくつかの動作に対してGNUがこれを行うかどうかは実際にはわかりませんが、次のようlnな事実を利用できます。

宛先パスが存在し、前のステップで作成された場合指定されていない診断メッセージを標準エラーに書き込む必要があるのかln​​、現在のソースファイルに対して何もせずに残りのソースファイルを処理し続けるのか、現在のsource_fileを処理し続けるのかを判断します。

ここで、「指定されていない」ビットは、ln少なくとも「前のステップ」を「ターゲットパスがシンボリックリンクです」と解釈できるようにする場合、GNUの動作に対する権限を付与できます。

このオプションのGNU文書は、ターゲットが-nオブジェクトへのシンボリックリンクである場合に焦点を当てています。目次:

'-n'
'--no-dereference'
     Do not treat the last operand specially when it is a symbolic link
     to a directory.  Instead, treat it as if it were a normal file.

     When the destination is an actual directory (not a symlink to one),
     there is no ambiguity.  The link is created in that directory.  But
     when the specified destination is a symlink to a directory, there
     are two ways to treat the user's request.  'ln' can treat the
     destination just as it would a normal directory and create the link
     in it.  On the other hand, the destination can be viewed as a
     non-directory--as the symlink itself.  In that case, 'ln' must
     delete or backup that symlink before creating the new link.  The
     default is to treat a destination that is a symlink to a directory
     just like a directory.

     This option is weaker than the '--no-target-directory' ('-T')
     option, so it has no effect if both options are given.

ターゲットがディレクトリへのシンボリックリンクである場合、GNUのデフォルトの動作はln新しいシンボリックリンクをディレクトリに配置することです(つまり、ディレクトリへのリンクを逆参照することです)。オプションで、診断メッセージをエクスポートして既存のリンクの宛先にアクセスできない場合は失敗します(標準テキストを許可)。

一方、OpenBSD(およびおそらく他のBSDシステム)は、ターゲットがオブジェクトへのシンボリックリンクであるときにlnGNUのように動作します。lnlnアクセシビリティただし、既存のリンクの宛先が次の場合、リンクは切断され、要求時にシンボリックリンクが再生成されます。いいえ入手しやすい。つまり、続行することを選択します(標準テキストでは許可されています)。

また、lnOpenBSDのGNUはOpenBSDネイティブと同様に動作しますがln、これはやや興味深いものです。

既存のシンボリックリンクを削除すると、rmそのディレクトリに対する書き込みおよび実行権限があるように見えるため、問題になりません。

関連情報