parse_user_cfg: correctly parse group names in ACLs
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).
we cannot fully close this window, and don't need to anyway since we
apply +-300s when calculating ticket age ranges, but documenting where
mtime is used and what we expect seems like a good idea for future
readers.
to shrink the window between the two file_set_contents calls. we don't
need the mtimes to line up exactly since we have 300s of uncertainty
anyway, but generating an RSA key could take a while ;)
tfa: realm required TFA should lock out users without TFA
This changed with the previous TFA changes.
In the long term, the plan is to let the user get into the
half-logged-in state and open the TFA configuration window
on the UI to allow them to finish their TFA setup, but for
now we restore the previous behavior.
Signed-off-by: Wolfgang Bumiller <w.bumiller@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>
verify_ticket: allow general non-challenge tfa to be run as two step call
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 reset auth key age until the first rotation has happened, otherwise
all currently existing tickets get invalidated immediately once the
rotation code gets enabled.
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.
Thomas Lamprecht [Mon, 12 Nov 2018 16:50:14 +0000 (17:50 +0100)]
fix #233: return cluster name on successful login
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>
Stoiko Ivanov [Thu, 21 Jun 2018 12:31:45 +0000 (14:31 +0200)]
refactor API using get/register_standard_option
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).
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>
Philip Abernethy [Thu, 21 Sep 2017 09:09:14 +0000 (11:09 +0200)]
fix #1501: pveum: die when deleting special role
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.
projects / pve-access-control.git / log