This was missing in commit20c60513b2a6b2d7c7aae0dcc0391889b9cb7ecf,
so user can't assign permisson on a zone currently
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
commit 42ade84744 added the pool
subcommands, reusing the PVE::API2::Pool module. But that module has
to live in pve-manager and is not available here, most of the time
not a real issue (but always ugly), on bootstrapping this becomes a
blocker though...
So, for now add a hack and do not hard depend on the modules
availability...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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>
Instead of 'common-auth' use 'proxmox-ve-auth', this way
users can override PAM authentication settings via
`/etc/pam.d/proxmox-ve-auth`.
If the file does not exist, pam will use `/etc/pam.d/other`
which by default behaves like `common-auth`.
Note that this *can* be different from directly using
`common-auth` *if* a user has actually modified
`/etc/pam.d/other` for some reason.
Signed-off-by: Wolfgang Bumiller <w.bumiller@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>
It seems that servers associate the client-cert/key with an account, so
doing an explicit anonymous bind then 'logs out' the already verified
user, limiting the search results in some cases
before refactoring to PVE::LDAP, we did not do '$ldap->bind' at all when
there was no bind_dn, but it is not really clear if Net::LDAP does this
automatically when searching (other libraries do this), so leave the
anonymous bind (for compatibility with PMG) but skip it when a client
certificate and key is given.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Allows a user to straight forward delete TFS over CLI, easier as
telling them to edit some config files, and the API is already there.
Short circuit most params of that API call to undef, as they do not
make sense to expose.
Signed-off-by: Thomas Lamprecht <t.lamprecht@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>
instead of having only a 'secure' flag which switches between
ldap/ldaps we now have a mode which also contains 'ldap+starttls'
our connection code in PVE::LDAP can handle this already (used in pmg)
so that is no problem
if we want to really remove the 'secure' flag, e.g. in 7.0
we'd either have to rewrite the config or have it as an error
in a pve6to7 script
Signed-off-by: Dominik Csapak <d.csapak@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>
