and related helper, to dump permissions + propagate info for
- a specific, given path
- generic top-level + user.cfg-referenced paths, including pools
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
this information is already available, but not exposed. we need it for
dumping an effective permission tree of a given user/token.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
non-privsep tokens will always return the roles/permissions of their
associated users. privsep tokens will return unfiltered roles, but
filtered permissions.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
which checks that the user and token exist and are not expired, and then
generates the string to be matched with the pmxcfs-stored token shadow
config file.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
with the format:
<full token ID> <token value/UUID>
it is just used for token value generation/deletion via the User API,
token value verification will happen over pmxcfs/ipcc.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
the helper is modeled after the corresponding user method.
the 'tokenid' option goes into PVE::AccessControl, since we need it in
multiple API modules.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
token definitions/references in user.cfg always use the full form of the
token id, consisting of:
USER@REALM!TOKENID
token definitions are represented by their own lines prefixed with
'token', which need to come after the corresponding user definition, but
before any ACLs referencing them.
parsed representation in a user config hash is inside a new 'tokens'
element of the corresponding user object, using the unique-per-user
token id as key.
only token metadata is stored inside user.cfg / accessible via the
parsed user config hash. the actual token values will be stored
root-readable only in a separate (shadow) file.
'comment' and 'expire' have the same semantics as for users.
'privsep' determines whether an API token gets the full privileges of
the corresponding user, or just the intersection of privileges of the
corresponding user and those of the API token itself.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
it was useful for test-cases to verify the behaviour when pools where
introduced, but it is not used anywhere else in the code base and those
tests can also just check on permission-level.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
they have been handled by PVE::RPCEnvironment for quite some time
already, and the versions there are the complete ones that should be
actually used.
manager switched over their last use not long ago, in 6.0-9, so
record a Breaks to that version.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
we already have the API paths, and they make sense to get an overview
over user.cfg contents.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
since libpve-cluster-perl 6.0-8 this happens automatically when parsing
the datacenter.cfg, just like the other property strings stored there.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
since we read datacenter.cfg, and parse the u2f property string using a
format defined in PVE::DataCenterConfig.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
this packge only contains perl modules and scripts, shell completions
and documentation - no architecture-specific stuff whatsoever.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
instead of parsing corosync.conf, and avoid coupling the access-control
API with PVE::Corosync. if corosync.conf and pmxcfs don't agree on how
the cluster is called, there is a bigger issue anyway..
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
it's not required for dependencies (since those are only ever between
sections, and not within), but makes for easier diffing.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
usernames are allowed to start with '@', so adding a user '@test@pve'
and adding it to an ACL should work, instead of ignoring that part of
the ACL entry.
So use verify_groupname to additionally enforce that the group name we
extracted does not include an additional @, as then it cannot be a
group.
note: there is no potential for user and group to be confused, since a
username must end with '@REALM', and a group reference in an ACL can
only contain one '@' (as first character).
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
