2.4.1. IDA pro 权限管理（2.4.1. Managing permissions）

If you want to limit access to the files that will be stored on the vault server, you can specify who can access what. By
default, the permission table grants all users access to all files:

>hv perm get
# The permission for each vault file is determined as the result of applying
# all matching lines, from the beginning of the permission table to the end.
# An empty permission table grants all access to everyone.
# A non-empty permission table starts by denying all access to everyone.

You will need to prepare a new permission table and put it into a file. The permission table consists of lines with the
following format:
ACTION CATEGORY WHO PERM PATH

where:
ACTION
one of "grant" or "deny"
CATEGORY
one of "user" or "group"
WHO
name of the user or group to match
PERM
one of "list", "read", "write"
PATH
path pattern that the rule is for
Below is a sample permission table:

NOTE

We’ll assume the server has been in use for a while, and holds some files in the directories subdir-for-
fred/, local-secret/, and subdir/for/idbs/.

# The permission for each vault file is determined as the result of applying
# all matching lines, from the beginning of the permission table to the end.
# An empty permission table grants all access to everyone.
# A non-empty permission table starts by denying all access to everyone.
# Fred can freely list, read, and modify all files inside "subdir-for-fred"
grant user fred write //subdir-for-fred/
# The "remote" group cannot even see "local-secret":
deny group remote list //local-secret
# The analysts can work on IDBs:
grant group analysts write //subdir/for/idbs/
# Everyone else may read them:
grant user * read //subdir/for/idbs/

The permissions have the following order:

• Adding the read permission also adds the list permission.
• Adding the write permission also adds the list and read permissions.
• Removing the read permission also removes the write permission.
• Removing the list permission also removes the read and write permissions.

Once the permission table is ready and stored in a file, we can install it:
>hv perm set @path/to/permission-file
After setting the permissions, it is a good idea to verify them. For example, this is how we can get a full list of files that
fred can see, with the rw or r- prefixes, depending on the permissions:

>hv perm check fred //
rw //subdir-for-fred/afile
rw //subdir-for-fred/anotherfile
r- //subdir/for/idbs/malware.idb

Or we could limit our check to a particular file:
>hv perm check fred //local-secret

The empty output means that fred cannot see local-secret even though it exists.

中文翻译：

如果想限制访问将存储在保险库服务器上的文件，可以指定谁可以访问什么。默认情况下，权限表授予所有用户对所有文件的访问权限：

hv perm get

#每个保险库文件的权限是通过从权限表开始到结束应用所有匹配行的结果来确定的。#一个空的权限表授予所有人所有访问权限。#非空的权限表首先拒绝所有人的访问权限。

#您需要准备一个新的权限表并将其放入文件中。权限表由以下格式的行组成：

ACTION CATEGORY WHO PERM PATH

其中：

ACTION

“grant”或“deny”之一

CATEGORY

“user”或“group”之一

WHO

要匹配的用户或组的名称

PERM

“list”、“read”、“write”之一

PATH

规则适用的路径模式

以下是一个样例权限表：

注意

我们将假设服务器已经使用了一段时间，并且在子目录subdir-for-fred/、local-secret/和subdir/for/idbs/中保存了一些文件。

#每个保险库文件的权限是通过从权限表开始到结束应用所有匹配行的结果来确定的。

#一个空的权限表授予所有人所有访问权限。

#非空的权限表首先拒绝所有人的访问权限。

#Fred可以自由列出、读取和修改“subdir-for-fred”中的所有文件：grant user fred write//subdir-for-fred/

#“remote”组甚至不能查看“local-secret”：deny group remote list//local-secret

#分析员可以处理IDB：grant group analysts write//subdir/for/idbs/

#其他人可以阅读它们：grant user*read//subdir/for/idbs/

权限的顺序如下：

•添加读取权限还会添加列表权限。

•添加写入权限还会添加列表和读取权限。

•删除读取权限也会删除写入权限。

•删除列表权限也会删除读取和写入权限。

设置好权限表并将其存储在文件中后，我们可以将其安装：

hv perm set path/to/permission-file

设置权限后，最好验证一下。例如，这是我们如何获取fred可以查看的所有文件的完整列表，具体取决于权限：

hv perm check fred//

rw//subdir-for-fred/afile

rw//subdir-for-fred/anotherfile

r-//subdir/for/idbs/malware.idb

或者我们可以限制我们的检查到特定的文件：hv perm check fred//local-secret

空输出表示fred无法看到local-secret，尽管它存在。