we normally use shift only in closures, to keep them short, as a
module method this should rather use our standard style.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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>
Can happen if the RTC is in the future during installation and first
boot, when during key generation the clock is in the future and then,
after the key was already generated, jumps back in time.
Allow a fuzz of $auth_graceperiod, which is currently 5 minutes, as
that fuzz allows some minor, not really problematic, time sync
disparity in clusters.
If an old authkey exists, meaning we rotated at least once, check it's
time too. Only rotate if it'd not be valid for any tickets in the
cluster anymore, i.e., if it difference between the current key is >
$ticket_lifetime (2 hours)..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
instead of dropping ACLs and group membership for missing users,
simply warn and leave it in the config
for users that get removed via the api this happens explicitely
this is to prevent that a 'faulty' ldapsync removes users temporarily
and with it all acls that the admin created
we still have a 'purge' flag for the sync where ACLs get removed
explicitly for users removed from ldap
also adapt the tests
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we do the same for missing users, groups and tokens, and just like
groups, roles with an empty privilege set are explicitly allowed so
pre-generating placeholders is possible.
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>
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>
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>
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.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
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 ;)
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
to fix an issue where valid tickets could be rejected 5 minutes after a
key rotation, where the minimum age is exactly 0 seconds.
thanks Dominik for triaging!
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
This activates the authkey rotation added in commits
1800a71a79c7cf49108e22781d2f34be87b1efd through
f7282aee6b
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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>
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>
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>
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>
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>
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>
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>
