タグ付けされた質問 「acl」

ACLはアクセス制御リストの略です。ACLは、ファイルに対する権限を、従来のuser-group-othersトリプルを超えて拡張します。

2
setfaclを使用して、グループメンバーがディレクトリ内の任意のファイルに書き込めるようにする
setfaclを使用して、「app」グループの誰もが、従来のUNIXのアクセス権の内容に関係なく、/ usr / local / users / appに含まれるファイルを編集できるようにしたいと思います。ジョンとベンという2人のユーザーがいます。別の質問の指示に従ってみましたが、johnが一部のファイルに書き込めません。これはaclマスクが原因です。しかし、私はrwxのディレクトリにデフォルトのマスクを設定したので、その中のファイルは作成時にそれを継承しないのですか? たとえば、ジョンは以下のファイルに書き込むことができませんが、彼はファイルに書き込みACLを持っているグループ「アプリ」のメンバーであるため、ファイルを編集できないことに驚いています。 ben@app1:/usr/local/users$ ls -la app/app-1.0-SNAPSHOT/lib/play.templates_2.10-2.1.1.jar -rw-r--r--+ 1 ben users 38326 Apr 2 10:21 app/app-1.0-SNAPSHOT/lib/play.templates_2.10-2.1.1.jar ben@app1:/usr/local/users/app$ getfacl app-1.0-SNAPSHOT/lib/ # file: app-1.0-SNAPSHOT/lib/ # owner: ben # group: users user::rwx group::rwx #effective:r-x group:app:rwx #effective:r-x mask::r-x other::r-x default:user::rwx default:group::rwx default:group:app:rwx default:mask::rwx default:other::r-x ben@app1:/usr/local/users$ getfacl app/app-1.0-SNAPSHOT/lib/play.templates_2.10-2.1.1.jar # …
12 permissions  acl 

2
umaskはACLにどのように影響しますか?
umaskACLがアクティブになっている場合、新しく作成されたファイルのデフォルトマスクにどのように影響するかを誰かに説明できますか?これに関するドキュメントはありますか? 例: $ mkdir test_dir && cd test_dir $ setfacl -m d:someuser:rwx -m u:someuser:rwx . # give access to some user $ getfacl . # file: . # owner: myUsername # group: myGroup user::rwx user:someuser:rwx group::--- mask::rwx other::--- default:user::rwx default:user:someuser:rwx default:group::--- default:mask::rwx default:other::--- $ umask # show my umask 077 …
12 linux  permissions  posix  acl 

1
FreeBSDがwマスクを失ったのに、Debianはそれを保持したのはなぜですか?
FreeBSD ACLとLinux ACLの動作の違いを理解しようとしています。特に、デフォルトACLの継承メカニズム。 Debian 9.6とFreeBSD 12の両方で以下を使用しました: $ cat test_acl.sh #!/bin/sh set -xe mkdir storage setfacl -d -m u::rwx,g::rwx,o::-,m::rwx storage touch outside cd storage touch inside cd .. ls -ld outside storage storage/inside getfacl -d storage getfacl storage getfacl outside getfacl storage/inside umask Debian 9.6から次の出力が得られます。 $ ./test_acl.sh + mkdir storage + …

1
getfaclが先頭の/を絶対パス名から削除するのはなぜですか?
私はCentOS / Red Hat 6のACLについて学んでいる最中です。getfacl絶対パスを使用して実行すると、次のような出力が得られます。 getfacl:絶対パス名から先頭の「/」を削除する なぜこれが必要なのですか?-pまたは--absolute-namesスイッチを使用する必要があるのはどのような場合ですか? Wale SoyinkaとMichael Jangによる私の本は、これについてはあまり言及していません。manページには手掛かりがなく、この警告に直接対処しているサイトを見つけることができません。
10 linux  filenames  acl 

1
setfacl:これら2つのコマンドは同じですか?
Symfony2インストールの特定のサーバーに権限を設定する(capifonyに基づく)デプロイメントスクリプトがあります。これには、いくつかのディレクトリに対してこれを行う次の2つのコマンドが含まれています。 setfacl -R -m u:www-data:rwx -m u:`whoami`:rwX app/cache setfacl -dR -m u:www-data:rwx -m u:`whoami`:rwX app/cache これら2つのコマンドは、権限を修正する方法としてSymfony2サイトにありますが、これらは私と非常によく似ていました。そのためsetfacl、のマンページを確認しました。理解できることから、2番目のコマンドは、最初のコマンドが追加オプションを使用して実行することとまったく同じです(完全には理解していません)。私の質問は、私の仮定は正しいですか?もしそうなら、最初のコマンドを削除しても同じ効果がありますか?
10 permissions  acl 

1
読み取り専用/リモートファイルシステムでのACLの使用
リモートでマウントされたファイルシステムで使用されるローカルACLを定義したいと思います。ファイルシステムはautofsとsshfs FUSEを介してマウントされます。 考えは、環境内の他のサーバー上のファイルを読み取るためのアクセス権を持つジャンプサーバーに投獄されたユーザーを設定し、多くの公開なしに、そして確かにsshアクセス権を付与せずに標準コマンドを使用できるということです。 問題は、sshfsは常に同じユーザーとして実行されるため、リモートシステムのパス内のファイルは、公開されたユーザーに関係なく公開されることです。 私はセキュリティチェックをsshfsに直接コーディングすることを検討しましたが、その道を進む前に、他のパッケージがACLサポートを他の方法で読み取り専用のファイルシステムに追加できるかどうかを確認したいと思います。 編集:@peterphリモートファイルシステムが読み取り専用の場合、NFS共有のACLをどのように設定しますか? sshfsは分解が本当に簡単だったので、これを書いてから数日後にACLチェックをsshfs自体に追加しました。ユーザーは、OpenSSHおよびjailkitを介してログインすると投獄され、そこから非特権ユーザーとして読み取り専用のsshfs automountにアクセスします。すべてのdir / file statまたはreadは、syslogイベントを生成します。それは魅力のように機能していて、ユーザーは1つの刑務所に入れられた箱からの権利を持ちません。
9 acl  sshfs  fuse 

1
POSIX.1eが廃止されたのはなぜですか?
提案されたPOSIX.1e標準は、広くサポートされているACLなどのいくつかを定義しています。しかし、提案自体は取り下げられました。どうして?私がオンラインで見つけた唯一の理由は、http://wt.tuxomania.net/topics/1999_06_Posix_1e/からのこの引用です: なぜPosix.1eが放棄されたかは、今日(2014年7月)の観点から理解するのは困難です。Solaris、Irix、Linux、そしておそらく他のUnicesが標準を認識しているようです。一方、FreeBSDプロジェクトは反対の引数を見つけ、デフォルトでは機能(「きめの細かい特権」)を統合しませんでした。 一方、JörgSchillingはこのサイトでこれを述べています(ファイルシステムACLの「マスク」の正確な目的は何ですか?) ところで、ACLのPOSIX-1003.1ドラフトは、1997年にリファレンス実装(ag Solaris)によって撤回されました。これは、顧客が、後でNVSv4 ACLとして標準化されたより強力な方法を望んでいることが判明したためです。 起こったことの詳細な説明はありますか?
9 posix  history  acl 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.