Syntax for permission paths is now checked on API calls for
creation or update on permissions.
Signed-off-by: Lorenz Stechauner <l.stechauner@proxmox.com>
keep variable names aligned with the params the relate to, "write"
was quite ambiguous too (write what?)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we want the api options to be optional, but only as long as there are
default values set in the realm config
since they are all marked as optional (else they would be required in
the api) this check did not work as intended
instead, set the result to the value of:
* the parameter
* the set default in the config
* the api default
in this order
if it is undef after this, raise a parameter exception
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This allows us to have a convenient way to set the desired default
sync options, and thus not forcing users to pass always all options
when they want to trigger a sync.
We still die when an option is neither specified in the domains
(realm) config nor as API/CLI parameter.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
keep the api call way smaller and clearer
On moving out some minor adaptions where made, e.g., we do not print
"remove user X" if we know that we'd add it again, but just print a
single "update user X" for that. Same for groups.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we may potentially also sync something else over this in the future,
for example PAM users from a specific group, so use a more general
name.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this api call syncs the users and groups from LDAP/AD to the
user.cfg
it also implements a 'full' mode where we first delete all
users/groups from the config and sync them again
the parameter 'enable' controls if newly synced users are 'enabled'
(if no sync parameter handles that)
the parameter 'purge' controls if ACLs get removed for users/groups
that do not exists anymore after
also add this command to pveum
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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>
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>
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>
as it was binary data, which can contain everything, including '\0',
and this was cut off, making it impossible to login after
registration, as a borked publicKey got saved in tfa.cfg
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This allows for doing OTP TFA in two steps, first login with normal
credentials and get the half-logged-in ticket, then send the OTP
verification for full login, same as with u2f was already possible.
This allows for a nicer UI, as OTP fields can be shown on demand, and
do not need to be visible by default.
The old way of sending the OTP code immediately with the initial
credentials request still works for backward compatibility and as
some API user may prefer it.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
to avoid a failed login if a broken corosync config is setup
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we have each privilege as property of the return object,
so we generate it from $valid_privs
this has the advantage that all privileges are well documented
with that api call
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
If a cluster is configured then return the cluster name on successful
login - if the user has Sys.Audit privileges on the '/' path (same
as for returning cluster info, like the join info path uses)
This is more for the reason that some admins do not want to expose
this to lesser privileged (API) users. While yes, you can
theoretically launch a (DDOS resembling) attack which stresses the
corosync network if you know the cluster_name (it's still encrypted
but you can back-calculate the multicast group membership info) you
need to be able to send multicast traffic on the corosync LAN -
which can be seen as a pretty big privilege anyway.
But, for now reduce permissions - we can more easily loosen them than
tighten without causing issues anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Pull out duplicated property definitions in the API into
register_standard_option/get_standard_option calls.
(All parameters, which are thus added to the API calls were optional).
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
