Adds a priv/tfa.cfg file usable in place of user.cfg.
(Otherwise the user.cfg can potentially grow too big with
u2f keys.)
Also contains some preparation code for u2f and
user-opt-in totp.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
since $authkey_lifetime is currently set to 0, we have to check this,
else we always fail to verify the VNC ticket
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
to reset auth key age until the first rotation has happened, otherwise
all currently existing tickets get invalidated immediately once the
rotation code gets enabled.
disabled until first PVE 6.0 package release
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
and modify checks to accept still valid tickets generated using the
previous auth key.
the slightly complicated caching mechanism is needed for reading the key and
its modification timestamp in one go while only reading and parsing it again if
it has changed.
the +- 300 seconds fuzzing is kept for slightly out-of-sync clusters, since the
time encoded in the tickets is the result of time() on whichever node the
ticket API call got forwarded to.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@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>
PVE::AccessControl::role_is_special now returns 0 instead of '' for false
(Schemavalidation did complain about '')
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
use the get_standar_mapping 'pve-password'
then we can get rid of the Term::ReadLine dependency
we use this change to only ask for the password once on
'pveum ticket'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
use a sub-command structure instead of abbreviated words, where useful.
Keep old commands as aliases.
Signed-off-by: Philip Abernethy <p.abernethy@proxmox.com>
Co-authored-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Fixes a problem where a non root@pam system administrator does not
sees the 'Permissions' tab for a storage in our WebUI.
Fixes commit a2c18811d3
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this was missing and lead to 'use of unitialized value $realm...'
and a not working second server if a bindpw was defined
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Die with a helpful error message instead of silently ignoring the user
when trying to delete a special role.
Also add a property to the API answer for possible later use by the
WebUI.
Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We accessed methods from PVE::Storage here but did not define a
"use PVE::Storage". This thus only worked if modules if the
PVE::Storage module got pulled in by something else, by luck.
Simply including said use statement is not an option because
pve-storage is already dependent from pve-access-control, and we want
to avoid cyclic dependencies, especially on the perl module level.
The reason the offending module was used in the first place here
stems from the way how this coarse grained permissions are
calculated.
We check all permission object paths for privileges for an user.
So we got all vmids and all storage ids and computed paths from them.
This works, but is overkill and led to this "illegal" module use.
Instead I opt to not generating all possible paths, but just check
the ones configured plus a small required static set of top level
paths - this allows to generalize handling of the special root@pam
and "normal" users.
It has to be noted that this method is in general just intended for a
coarse capability check to allow hiding a few UI elements which are
not generated by backend calls (which are already permission aware).
The real checks get done by each backend call, automatically for
simple ones and semi-automatically for complex ones.
This adds 4 more options to the ldap authentication method:
verify: boolean
If enabled, the server certificate must be valid
capath: path to a file or directory
The CA to use to verify the server certificate. Used only
if 'verify' is true.
cert: path to a certificate
Used as client certificate when connecting to a server,
provided 'secure' is true. Requires 'certkey' to be set.
certkey: path to the certificate's key
Required only used when 'cert' is used.
