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

特定のユーザーのファイルの有効なアクセス許可をテストすることはできますか？ 私は通常これをしてsu userからファイルにアクセスしますが、今はシェルを持たないユーザー（つまりシステムユーザー）でこれをテストしたいです

24 permissions 

私は自分のユーザーとしてFUSEファイルシステムを問題なく使用していますが、rootはFUSEマウントにアクセスできません。代わりに、どのコマンドでもが与えられPermission deniedます。これらのマウントを読み取る許可をルートに与えるにはどうすればよいですか？ ~/top$ sudo ls -l total 12 drwxr-xr-x 2 yonran yonran 4096 2011-07-25 18:50 bar drwxr-xr-x 2 yonran yonran 4096 2011-07-25 18:50 foo drwxr-xr-x 2 yonran yonran 4096 2011-07-25 18:50 normal-directory ~/top$ fuse-zip foo.zip foo ~/top$ unionfs-fuse ~/Pictures bar 私のユーザーyonranはそれをうまく読むことができます： ~/top$ ls -l total 8 drwxr-xr-x 1 yonran yonran …

24 permissions  fuse 

tarユーティリティを使用してファイルをバックアップに保存すると、拡張ACLが失われます。 ACLを保持するために、一般的に使用される、ハックではないソリューション（ACLをゼロから再作成するスクリプトを作成するなど）はありますか？

24 acl  tar  backup  permissions 

たとえば、同僚に特定のディレクトリへの書き込みアクセスを許可したいとします。その中のサブディレクトリにアクセス権775、ファイル664があり、さらにdir-775にいくつかの実行可能ファイルがあったと仮定しましょう。 次に、書き込み権限を追加します。chmodを使用すると、次のようなことができます chmod o+w -R mydir/ しかし、それはクールではありません。ディレクトリを誰でも書き込み可能にしたくないからです。特定のユーザーにのみアクセスを許可したいので、ACLを使用します。しかし、これらのアクセス許可を設定する簡単な方法はありますか？ご覧のとおり、少なくとも3つのケース（ディレクトリ、ファイル、実行可能ファイル）に個別に取り組む必要があります。 find -type d -exec setfacl -m u:colleague:rwx {} \; find -type f -executable -exec setfacl -m u:colleague:rwx {} \; find -type f \! -executable -exec setfacl -m u:colleague:rw {} \; このような単純なタスクには、かなり多くのコード行があるようです。もっと良い方法はありますか？

24 linux  bash  permissions  acl 

Practical Unix and Internet Securityを読んでいたとき、理解できない次の行に出くわしました。 wuアーカイブサーバーを使用している場合は、アップロードされたファイルがモード004でアップロードされるように構成して、別のクライアントがダウンロードできないようにすることが できます。これは、単にディレクトリを読めないようにするよりも優れた保護を提供します。これは、人々がファイルをアップロードし、友人にダウンロードする正確なファイル名を伝えることを防ぐためです。 004の許可はに対応し-------r--ます。読み取りアクセス権がある場合、ファイルをダウンロードできませんか？また、単にディレクトリを読み取り不可能にするよりも良いと考えられるのはなぜですか？これは何を意味しますか？ 注：これは、許可されていないユーザーが匿名FTPを使用して違法で著作権で保護された素材をサーバーに残すことに関するものです。上記の解決策は、一定期間後にディレクトリの内容を削除するスクリプトとともにこれを防ぐために提案されました。

23 files  permissions 

この問題は、UnixおよびLinux Stack Exchangeで回答できるため、Server Faultから移行されました。 6年前に移行され ました。 Fedora 19に画面をインストールしました。SSHを介してrootとしてコマンドをリモートでテストすると、完全に機能します。たとえばscreen、新しい端末を入力すると、エミュレータが起動し、コマンドを待ちます。デタッチできます。しかし、SSHを介して標準ユーザーとしてリモートでログインすると、同じことをしようとすると、コマンドはすぐに終了します。私が見る唯一のメッセージはです[screen is terminating]。 誰かがすでにこの問題を抱えていますか？不正なアクセス許可に関連していますか？ 更新： $ strace -e trace=file screen execve("/usr/bin/screen", ["screen"], [/* 23 vars */]) = 0 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libutempter.so.0", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = …

23 permissions  gnu-screen 

私が理解していることから、独自のスクリプトを配置する適切な場所は/usr/local/bin（たとえば、いくつかのファイルをバックアップするために使用するスクリプト）です。このフォルダは現在（デフォルトで）rootによって所有されており、私の通常のユーザーはこのフォルダにアクセスできません。私はこのコンピューターの唯一のユーザーです。このフォルダ全体を自分のユーザーに変更しますか？または、のアクセス許可を配置する別の適切な方法はあり/usr/local/binますか？

23 permissions  directory-structure  fhs 

私はssh自分のコンピューターにリモートコンピューターからファイルを転送しようとしています： scp My_file.txt user_id@server:/Home これで、My_file.txtが自分のコンピューターのホームフォルダーに配置されるはずです。私は得る scp / Home：許可が拒否されました また、試してみると：...@server:/Desktop、リモートコンピューターからデスクトップにファイルをコピーするため。 何が間違っていますか？

23 ssh  permissions  scp 

ハッカーが問題を引き起こしている私のtmpディレクトリにファイルをドロップしました。スクリプトが失敗しているため、GBのerror_logエントリを作成する以外、悪意はありません。ただし、実行に使用しているファイルには権限がなく、ROOTであってもこのファイルを削除または名前変更することはできません。 ---------- 1 wwwusr wwwusr 1561 Jan 19 02:31 zzzzx.php root@servername [/home/wwwusr/public_html/tmp]# rm zzzzx.php rm: remove write-protected regular file './zzzzx.php'? y rm: cannot remove './zzzzx.php': Operation not permitted 私もiノードで削除しようとしました root@servername [/home/wwwusr/public_html/tmp]# ls -il ... 1969900 ---------- 1 wwwusr wwwusr 1561 Jan 19 02:31 zzzzx.php root@servername [/home/wwwusr/public_html/tmp]# find . -inum 1969900 …

22 linux  permissions  filesystems 

特定のユーザーの読み取り/書き込みアクセス権を持つデバイスをマウントするにはどうすればよいですか？

22 filesystems  permissions  mount  authorization 

SELinuxがシステムにインストールされている場合、標準のLinux許可の前後にルールが適用されますか？たとえば、非ルートLinuxユーザーがLinuxパーミッションでファイルに書き込もうとすると、-rw------- root rootSELinuxルールが最初にチェックされますか、それとも標準ファイルシステムパーミッションが適用され、SELinuxは呼び出されませんか？

22 files  permissions  selinux  access-control 

私は以下のようなフォルダ内にいくつかのディレクターがいます- teckapp@machineA:/opt/keeper$ ls -ltrh total 8.0K drwxr-xr-x 10 teckapp cloudmgr 4.0K Feb 9 10:22 keeper-3.4.6 drwxr-xr-x 3 teckapp cloudmgr 4.0K Feb 12 01:44 data 私はこのようなこのようなものにアクセス許可を変更する必要があるいくつかの他のマシンにもいくつかの他のフォルダを持っていますdrwxr-xr-x。 つまり、どのようにフォルダのアクセス許可を変更できますdrwxr-xr-xか？私chmodはこれでコマンドを使用する必要があることを知っていますが、これに使用すべきchownの値は何ですか？

22 linux  permissions  chmod 

多数のユーザー間で共有されるデータを含むディレクトリがあります。このディレクトリおよびその下にあるものへのアクセスは、問題のユーザーに追加されるディレクトリのグループによって制御されます。そのため、「スティッキグループ」chmod g+sセットのフォルダを作成しました。ディレクトリには、ディレクトリとファイルのツリー構造が含まれます。ファイルの合計量はおそらく数百万です。ファイルはかなり小さくなり、50MBを超えるものは予想していません。 私の問題は、ファイルまたはディレクトリの所有者がまだそれを作成したユーザーであることです。そのため、アクセスグループからそのユーザーを削除する必要がある場合でも、彼のアクセスを完全には削除しません。 そう： すべてのファイルとサブディレクトリの所有者を同じにするために見逃した他のオプションはありますか？ cronジョブを使用して定期的にディレクトリ全体を閲覧できると思いますが、基本的には1回しか実行されないコマンドに対しては非効率的だと思います。 INotifyを使用した例を見つけましたが、スクリプトを作成する必要があるため、メンテナンスの手間がかかります。 ACLが所有権の強制に役立つかどうかはわかりませんでした。 これを行うよりスマートな方法はありますか？ 私が欲しいのは、ユーザーにグループを追加することで共有できるディレクトリを持つことです。このディレクトリで作成されたものはすべて、その親から許可スキームを継承します。私がしようとしているものよりも良い方法があれば、私はすべて耳です。

21 debian  permissions  filesystems 

* nixシステムでのファイルパーミッションについてはかなり単純な理解があります。ファイル所有者とファイルグループが存在することは理解していますが、そのファイル所有者もファイルグループに所属する必要があるかどうかについて、厳格なルールがありますか？または、別の言い方をすれば、ファイルは所有者が所属していないグループに属することができますか？ ある場合（またはそうでない場合）、なぜですか？私は理解を深めたいと思います...インターウェブ上でこれについて具体的に述べているものを見つけることができないようです...私はまた、このテーマに関するいくつかの良い読書資料を受け入れています。

21 permissions  group 

Linuxでのファイルのアクセス許可の仕組みを理解していると思います。ただし、なぜ2つではなく3つのレベルに分割されているのか、私にはよくわかりません。 次の問題に回答してください。 これは意図的な設計ですか、それともパッチですか？つまり、所有者/グループのアクセス許可は、何らかの論理的根拠とともに設計および作成されたのか、それとも次々にニーズに答えるために来たのか？ ユーザー/グループ/その他のスキームは有用だが、グループ/その他のスキームでは十分ではないシナリオはありますか？ 最初の質問に対する回答は、教科書または公式の掲示板のいずれかを引用する必要があります。 私が検討したユースケースは次のとおりです。 プライベートファイル-ユーザーごとにグループを作成することにより、非常に簡単に取得できます。これは多くのシステムでよく行われています。 所有者（システムサービスなど）のみにファイルへの書き込みを許可し、特定のグループのみに読み取りを許可し、他のすべてのアクセスを拒否します-この例の問題は、グループが書き込みアクセスを持つ必要がある場合/ group / otherはそれで失敗します。両方の答えはACLを使用することであり、私見では、所有者の許可の存在を正当化しません。 NB superuser.comで質問を閉じた後、この質問を改良しました。 EDITが「... group / other ...」に「ただし、グループ/所有者スキームでは不十分」を修正しました。

21 linux  permissions