Users Permissions

Passwords storage in the OS's keychain

While hosts, user names & site names are persisted to the registry, passwords are stored securely in the operating system's keychain.

• On Windows, the Windows Credential Store is used (therefore requiring Windows 7 or newer)

• On macOS, the macOS Keychain is used

• On Linux, the "Secret service" is used (through libsecret-1)

Managing permissions on a vault

The vault_server includes a way to restrict the access of users and groups to the data stored in the vault_server.

The permission file is a text file that contains the permission table. The file consists of lines that grant or deny access to certain path patterns in the vault. The syntax for an entry is the following:

grant/deny group/user NAME PERMISSION VAULT_PATH_PATTERN

Possible PERMISSION values are: list, read and write. read includes list, write includes read (and thus also includes list).

Example of a permission file:

# deny everything to everyone. no need to specify it explicitly,
# it is the default for a non-empty permission table:
# deny  user *      list  //*

deny  user *      list  //secret/   # nobody can see //secret. this line is superfluous
                                    # because everything is denied by default.
grant user hughes write //secret/   # but hughes can write to secret and its subdirs
grant user john   read  //secret/   # and john can read the entire directory.
deny  user *      list  //secret/supersecret # supersecret is not visible to anyone
grant user hughes write //secret/supersecret # but hughes can modify it (john cannot)
grant user *      write //local_files/ # everyone can work with 'local_files'
deny group remote list //local_files/  # except that the 'remote' group cannot see 'local_files'

An empty permission table means that no permissions are enforced rendering all files accessible by everyone. As soon as a non-empty permission table is specified, all access is denied to everyone by default.

Path patterns may refer to (yet) unexisting files. Users and groups too may refer to unexisting users and groups.

The order of the permission file is important as the last lines will take precedence over the preceding lines (if there are conflicts).

Admins are not affected by the permission table, they are granted all access.

To install a new permission table, use perm set command (See HV Reference). The current permissions can be retrieved using perm get.