web-dev-qa-db-ja.com

非ルートの疑問符としてのLinuxローカルディレクトリの権限

さて、それは新しいものです。このようなストレージデバイスに障害が発生したり、リモートストレージ（SAN、NAS）に障害が発生したりするケースを見たことがありますが、マウントの権限によって引き起こされる同様の問題を見たことがあると思います。しかし、これが私のホームディレクトリと同じファイルシステムで発生しているのを見るのは初めてです...

私はそれについて非常に興味があります...どのような許可がここで蹴られていますか？確かにマウントしない（同じext4ファイルシステム上にある）、SELinuxではなく、ACLではありません。じゃあ何？？？

このディレクトリがどのように作成されたか思い出せません。何らかのソフトウェアによって作成された可能性があります。

私にとって最も奇妙な部分は、ディレクトリがその親の情報を見ることが許可されていないことです（最後のコマンド）...

Linux Mint Sarah

user01@MyPC ~/somedirectory $ ls -l ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D\:
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:/workspace': Permission denied
viso 0
d????????? ? ? ? ?            ? workspace
user01@MyPC ~/somedirectory $ ls -ld ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D\:
drw-r--r-- 3 user01 user01 4096 Rgs 27  2016 ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:
user01@MyPC ~/somedirectory $ 
user01@MyPC ~/somedirectory $ 
user01@MyPC ~/somedirectory $ ls -l ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D\:
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:/workspace': Permission denied
viso 0
d????????? ? ? ? ?            ? workspace
user01@MyPC ~/somedirectory $ 
user01@MyPC ~/somedirectory $ 
user01@MyPC ~/somedirectory $ Sudo file ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D\:
./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:: directory
user01@MyPC ~/somedirectory $ Sudo ls -l ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D\:
viso 4
drwxr-xr-x 3 user01 user01 4096 Rgs 27  2016 workspace
user01@MyPC ~/somedirectory $ Sudo stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D\:
  File: './deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3937216     Links: 3
Access: (0644/drw-r--r--)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 12:57:33.990819052 +0300
Modify: 2016-09-27 11:18:38.309775066 +0300
Change: 2017-03-13 14:56:40.960468954 +0200
 Birth: -
user01@MyPC ~/somedirectory $ Sudo getfacl ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D\:
# file: deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:
# owner: user01
# group: user01
user::rw-
group::r--
other::r--

user01@MyPC ~/somedirectory $ stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D\:
  File: './deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3937216     Links: 3
Access: (0644/drw-r--r--)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 12:57:33.990819052 +0300
Modify: 2016-09-27 11:18:38.309775066 +0300
Change: 2017-03-13 14:56:40.960468954 +0200
 Birth: -
user01@MyPC ~/somedirectory $ stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D\:/workspace
stat: nepavyksta patikrinti './deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:/workspace': Permission denied
user01@MyPC ~/somedirectory $ Sudo stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D\:/workspace
  File: './deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:/workspace'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3937217     Links: 3
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 12:58:46.845727190 +0300
Modify: 2016-09-27 11:18:38.309775066 +0300
Change: 2016-12-02 13:56:08.298109826 +0200
 Birth: -
user01@MyPC ~/somedirectory $ stat .
  File: '.'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3278479     Links: 23
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 09:46:22.102269130 +0300
Modify: 2017-09-20 17:33:04.564009275 +0300
Change: 2017-09-20 17:33:04.564009275 +0300
 Birth: -
user01@MyPC ~/somedirectory $ ll ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D\:/
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:/workspace': Permission denied
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:/.': Permission denied
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:/..': Permission denied
viso 0
d????????? ? ? ? ?            ? ./
d????????? ? ? ? ?            ? ../
d????????? ? ? ? ?            ? workspace/
user01@MyPC ~/somedirectory $

属性：

user01@MyPC ~/somedirectory $ Sudo lsattr ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D\:/
-------------e-- ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:/workspace
user01@MyPC ~/somedirectory $ Sudo lsattr ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D\:/workspace
-------------e-- ./deploy_dir/liferay-portal-6.1.1-ce-ga2/Tomcat-7.0.27/bin/D:/workspace/directory2
user01@MyPC ~/somedirectory $
permissionsfilesystemsdirectory
8
netikras

ファイルについては、アクセス許可を確認するのに十分です。それらをlsするには、フォルダーを読み取って実行する必要があります。

chmod -R a+X ./deploy_dir

実行のみを設定する大文字のX（および実行ビットが既に設定されているファイル）。

17
HoD

ファイルの権限を読み取るには、そのファイルでstat(2)を呼び出す必要があります。また、ファイルを含むディレクトリ（パス内のすべてのディレクトリ）に対する実行/アクセス権限が必要です。これは実際には、ファイル名を取る他のすべてのシステムコールと同じです。ただし、ディレクトリーの内容（ファイル名のリスト）を読み取るには、ディレクトリーに対する読み取りアクセスのみが必要です。

サンプルスニペットでは：

_~/somedirectory $ ls -l .../bin/D\:
ls: negaliu pasiekti '.../bin/D:/workspace': Permission denied
viso 0
d????????? ? ? ? ?            ? workspace
_

lsがstat(".../bin/D:/workspace")を呼び出そうとしたところ、エラーが発生し、不満が出ました。一部のシステムでは、readdirを使用しなくても、ファイル名とともにgetdents/stat呼び出しから部分的な情報を取得できます。このように、workspaceはディレクトリであることが示されています。

ここでは、どのユーザーにもXビットがないことがわかります。

_~/somedirectory $ ls -ld .../bin/D\:
drw-r--r-- 3 user01 user01 4096 Rgs 27  2016 .../bin/D:
_

Rootになると、完全なリストが表示されます。これは、rootになると許可ビットが完全に無視されるためです。

7
ilkkachu

ファイル属性を確認するには、ディレクトリを読み取る権限が必要です。これが不可能な場合は、疑問符が表示されます。

そのユーザーが情報を読み取れない理由については、ディレクトリの属性（.../D:/.上記）。別の考えられる原因は、ディレクトリが削除されているか、アクセスモードとは異なる理由でアクセスできない（ネットワークファイルシステム、古いハンドルなど）場合です。

1
Ned64

今日、私は非常によく似た問題を抱えており、同様の症状がありました。許可と所有権のフィールドに疑問符があり、root/Sudoを使用しても、これを変更することはできませんでした。次に、この特定のディレクトリが実際にはWindowsファイル共有上のディレクトリへのマウントポイントであることを思い出しました。その間にアンマウントされました。 mount.cifsコマンドを再発行し、ネットワークのWindows部分の資格情報を入力した後、「ls」がディレクトリの通常の権限と所有権情報を報告しました。症状はあなたの症状とまったく同じに見えたので、「D：」はWindows風に見えるので、同様の状況にあるのではないかと思います。

0
davino