facl、setfacl、ディレクトリ共有、cpが元のファイル権限をfaclマスクに入れるのはなぜですか？これはcp -pアクションと見なされませんか？

このシステムのユーザーは注意を払ってumaskを非常に個人的な0077に設定しました。ただし、ユーザーは他のグループメンバー間で明示的に共有できるようにファイルをコピーできるグループ固有のディレクトリを持っていることを望みます。これらの共有ディレクトリは複数ありますが、各ディレクトリはグループによって異なります。

共有のために特定のディレクトリにグループ固定ビットを設定するだけでは不十分です。固定ビットを設定すると、ディレクトリ内のファイルのグループ所有権が正しく設定されますが、そのファイルに対する権限は通常、ファイルを読み取ったり編集したりできないように、つまり実際に共有できないように設定されます。ディレクトリリストにのみ表示されます。これは、一部のユーザーが、読み取りおよび書き込みを許可するために必要なグループ権限の調整を手動で実行する方法を望まないかわからないためです。結局のところ、ユーザーは管理者ではないので、しばらく休むことができます。 アクセス制御リストaclを持たないグループの権限に関係なく、特定のグループが共有ディレクトリのファイルにアクセスできるように指定するために使用できます。完璧なソリューションですが、うまく動作しません。

以下では、共有グループは「customer_gateway」であり、ファイルを共有したいユーザーの例は「svw」です。スクリプトが示すように、svw ユーザーは customer_gateway グループのメンバーです。共有が行われるディレクトリは「customer_gateway/」とも呼ばれます。

以下はaclを使用します。グループ権限、デフォルトグループ権限、マスク、およびデフォルトマスクを設定します。これはディレクトリに作成されたファイルまたはcat（またはtar）を介して移動されたファイルに対しては機能しますが、奇妙なことに、そこに「cp」があるファイルでは機能しません。

# rm -r customer_gateway/
# umask
0077
# cat ~/script1

mkdir customer_gateway
chown :customer_gateway customer_gateway/
chmod g+rwx  customer_gateway/
setfacl -m group:customer_gateway:rwX customer_gateway/
setfacl -m d:group:customer_gateway:rwX customer_gateway/
setfacl -m m::rwX customer_gateway/
setfacl -m d:m::rwX customer_gateway/
getfacl customer_gateway
cd customer_gateway
touch cga
cat << EOF > cgb
c g b
EOF
ls -l

# . ~/script1
# file: customer_gateway
# owner: root
# group: customer_gateway
user::rwx
group::rwx
group:customer_gateway:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:customer_gateway:rwx
default:mask::rwx
default:other::---

total 4
-rw-rw----+ 1 root root 0 Mar  2 20:43 cga
-rw-rw----+ 1 root root 6 Mar  2 20:43 cgb

# su - svw
/home/svw/bin:/usr/local/bin:/usr/bin:/bin

(note umask is 0077)

> cd /share/customer_gateway/
> groups
svw adm dip video plugdev google-sudoers customer_gateway
> cat >> cga
e f g
> cat > cgc
c g c
> ls -l
total 12
-rw-rw----+ 1 root         root         6 Mar  2 20:44 cga
-rw-rw----+ 1 root         root         6 Mar  2 20:43 cgb
-rw-rw----+ 1 svw svw 6 Mar  2 20:44 cgc
> ls ~/dat
ta  tb  tc
> cat ~/dat/ta > ta
> cp ~/dat/tb tb
> ls -l
total 20
-rw-rw----+ 1 root         root         6 Mar  2 20:44 cga
-rw-rw----+ 1 root         root         6 Mar  2 20:43 cgb
-rw-rw----+ 1 svw svw 6 Mar  2 20:44 cgc
-rw-rw----+ 1 svw svw 4 Mar  2 20:45 ta
-rw-------+ 1 svw svw 4 Mar  2 20:45 tb
> getfacl ta
# file: ta
# owner: svw
# group: svw
user::rw-
group::rwx          #effective:rw-
group:customer_gateway:rwx  #effective:rw-
mask::rw-
other::---
> getfacl tb
# file: tb
# owner: svw
# group: svw
user::rw-
group::rwx          #effective:---
group:customer_gateway:rwx  #effective:---
mask::---
other::---
> 

これは、ディレクトリにファイルが作成されたときにデフォルトの権限を受け取り、共有できることを示します。しかし、ユーザーは常にそこにファイルを作成するわけではなく、通常はそこにファイルをコピーします。

しかし、コピーを作成することも同じです。なぜなら、コピーを作成する前に新しいファイルを作成する必要があるからです。ここでは、許可予約コピーではなく、一般コピーについて話しています。次の形式です。ただし、元のグループの権限に関係なく、ディレクトリで共有されるファイルが機能してコピーされます。

cat < data.in  > shared/data.out

うまく機能し、タールパイプを通しても機能しますが、

cp data.in shared/data.out

失敗する。 edcatファイルにはデフォルトマスクとデフォルト権限があります。 edcpファイルはcp -pのように、aclマスクとグループの権限内で権限を保持するため（そうでない）、有効な権限はaclが設定したものではなく元のファイルのように読み取られます。

2回目の試みでは、グループ固定ビットchmod g + rwxsとfacl変更を使用してこの実験を実行し、まったく同じ結果を得ました。ただし、すべての共有ファイルにグループの所有権が表示されるため、ディレクトリのリストがより美しいです。また、setfaclを使用して実行せずにグループ固定ビットを設定しました。コピーされたファイルにも同じ結果が適用されます（したがって、faclsは共有のためにファイルがコピーされるディレクトリには多少役に立たないようです）。

Linux faclsが生成されたデータのさまざまな形式を区別するための基礎と理由は何ですか？ cpが権限を維持するように指示せずに強制的に権限を維持するのはなぜですか？うまくいきますが、cpはうまくいかないtarでキャットとパイピングの違いによる混乱を正当化する理由はありますか？この区別をなくす魔法呪文を逃しているのでしょうか？

この要約は正しいですか？ faclsを使用すると、共有ファイルの所有権を克服できます。ファイルを「作成」するとき、生成はcpコマンドによるものであり、妥当な理由がある場合を除き、umaskよりも権限が許可されます。なぜ？