facl、setfacl、ディレクトリ共有、なぜcpは元のファイルのパーミッションをfaclマスクに入れるのですか？ 'それはcp-pの動作であるべきではありませんか？

このシステムのユーザーは注意して、umaskを非常にプライベートな0077に設定しています。ただし、ユーザーは、ファイルが配置されるグループ固有のディレクトリを作成したいと考えています。他のグループメンバー間で明示的に共有するためにコピーすることができます。それぞれがグループに固有ですが、そのような共有ディレクトリが複数存在する場合があります。

共有に使用する特定のディレクトリのグループスティッキービットを設定するだけでは不十分です。スティッキービットを設定すると、ディレクトリに配置されたファイルのグループ所有権が正しくなりますが、多くの場合、ファイルのアクセス許可は、ファイルを読み取ったり編集したりできないように設定されます。つまり、実際には共有できません。それらはディレクトリリストに表示されるだけです。これは、一部のユーザーが、読み取りと書き込みを許可するために必要なグループ権限の調整を手動で行うことを考えていないか、その方法を知らないためです。結局のところ、ユーザーは管理者ではないので、これをやめることができます。 acls を使用すると、aclsがない場合のグループのアクセス許可とは関係なく、特定のグループが共有ディレクトリ内のファイルにアクセスできるように指定できます。これは完璧なソリューションですが、完全には機能していません。

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

以下では、aclsを使用しています。グループのアクセス許可、デフォルトのグループのアクセス許可、マスク、およびデフォルトのマスクを設定しました。ディレクトリ内に作成されたファイル、または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::--- > 

これが示すのは、ファイルがディレクトリに作成されると、デフォルトのアクセス許可を受け取り、共有可能であるということです。ただし、ユーザーは常にファイルを作成するわけではなく、通常はそこでcpします。

ただし、コピーを実行するには、最初に新しいファイルを作成する必要があるため、コピーを実行することも同じです。ここではプレーンコピーであり、権限の保持コピーではありません。これは次の形式と同じです。btwは機能し、元のグループ権限とは関係なくディレクトリで共有可能なファイルをコピーします。

cat < data.in > shared/data.out 

正常に機能し、tarを介したパイピングも機能しますが、フォーム

cp data.in shared/data.out 

は失敗します。cat edファイルは、デフォルトのマスクとデフォルトのアクセス許可を取得します。cp edファイルは、そのアクセス許可をaclマスクとグループのアクセス許可に保持します。 cp -p（ただし、そうではありませんでした）、したがって、有効なアクセス許可は、aclsが設定されているものではなく、元のファイルのように読み取られます。

2回目の試行として、この実験をグループスティッキービット、chmod g + rwxs、およびfacl chアンジュ、そしてまったく同じ結果を得ました。ただし、すべての共有ファイルにグループの所有権が表示されるため、ディレクトリリストはよりきれいになります。また、setfaclを使用せずに、グループスティッキービットを設定して実行しました。コピーされたファイルについても同じ結果が得られました（したがって、ファイルがコピーされて共有されるディレクトリでは、faclはかなり役に立たないように見えます）。

linux faclは、どのような基準で、どのような理由で、データを作成しますか？これを行うように指示されていないのに、なぜcpにパーミッションを保持するように強制するのですか？猫とタールを介した配管の区別によって引き起こされる混乱を正当化するのはなぜですか？cpは機能しませんか？この区別を行う魔法の呪文がありませんか？蒸発しますか？

この要約は正しいですか：faclsを使用すると、ファイルを共有するための所有権を克服できます。ファイルを「作成」するときに、その作成がcpコマンドによるものでない限り、アクセス許可はumaskよりも許容されます。理由は…理由は？

コメント

• どのオペレーティングシステム（Linuxディストリビューションとバージョン）とどのファイルシステムを使用していますか？おそらくこの目的のために専用のシェルスクリプトを介して、人々にcatを使用させても大丈夫ですか？
• グループ内のすべてのユーザーが変更または削除できるようにしますか？任意のファイル、または作成者のみがそのようなアクセス許可を持っている必要がありますか？言い換えると、oの読み取りアクセス許可（および場合によっては実行アクセス許可）のみ
• Debian 10.ファイルの作成が機能するため、’コピーをtarにパイプしました。 ‘これをproj_cpコマンドとして/ usr / local / binにパッケージ化します。ただし、ユーザーが特別なコピーコマンドを使用する必要がある場合は、faclを使用せずにグループスティッキービットを使用して、アクセス許可を設定することができます。 cat tar および cpが機能するようにaclsを設定する方法を知りたいです。’ cpの動作ではなくcp-pの動作を実行しているため、cpのaclsに問題があると考えています。 ‘権限の専門家からの連絡を楽しみにしています。
• ご指摘のとおり、グループの共有はさまざまな問題で繰り返し発生します。この場合、ソフトウェア開発者はテストリリースディレクトリにアクセスできます。いじくりまわすのは彼らのものです。彼らはそのディレクトリで作業し、プッシュ、プル、仮想環境にインストールするなどできます。問題は、作業中の別の領域からコピーして、umaskにグループ権限が設定されていない場合に発生します。ファイルの作成とtarによるコピーは正常に機能するため、混乱を招きます。 cpが行うことを実行するだけのコピースクリプトを提供しなければならないのも面白いです。 ‘ acls ‘彼らは魔法です私はLOLと言います
• 私はアクセシビリティの専門家ではありませんが、私の質問を願っていますそしてあなたの答えは専門家があなたに関連する答えを与えるのを助けることができます。