The associated pve_verify_vmid() method already restricts the value
to this range, but this wouldn't be visible in the API viewer for
example [0].
The verify method is also called by qemu-server's qmextract, so it's
not possible to just drop the method right now.
[0]: https://forum.proxmox.com/threads/128845/post-564526
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
if a real json boolean is sent via the api, $value is a
JSON::PP::Boolean here instead of a string/scalar
so we should validate that too
the $value itself can be used normally in conditions like
----
if ($value) {
----
if the value is stringified, the result is either '1' or '0' so even if
we have some explicit checks like that it should not make a problem
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
There are some use sites, e.g. HA manager, pvescheduler that
incorrectly use priority level 'warn'. Likely because that is allowed
for some other log helpers in the codebase. Instead of fixing them all
one-by-one, simply allow 'warn' as a priority too.
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
This fixes an issue with LDAP servers that accept anonymous binds with
a non-empty password: If a user exists in the PVE LDAP realm, but PVE
cannot find the corresponding LDAP entry during login, they could log
in with any non-empty password.
This issue affects only LDAP realms. AD realms are not affected
because they perform no username->dn mapping.
At least the following LDAP server configurations seem to accept a
bind with empty DN and non-empty password and are affected:
* OpenLDAP with anonymous binds and the non-default setting
`olcAllows: bind_anon_cred` enabled.
* AD (when used in an LDAP realm instead of an AD realm). However, for
the issue to trigger, the LDAP search for the username->dn mapping
has to succeed but return zero results. This can happen, for
example, if the LDAP realm has (1) a bind DN set or (2) no bind DN
set and AD was manually configured to allow anonymous LDAP searches
for user entries.
The situation that a user exists in the PVE realm but is missing in
the LDAP directory can occur, for example, (1) if the user was created
manually or (2) if the LDAP entry is deleted or the base DN is
changed, but the LDAP realm has not been re-synced with
remove-vanished.
The username->dn mapping is performed by `get_user_dn`, which performs
an LDAP search. If the LDAP search for the user entry succeeds but
returns zero results (e.g. if the entry does not exist), `get_user_dn`
returns undef. Then, `auth_user_dn` is called with $dn being undef and
the user-provided $pw and performs an LDAP simple bind with these
credentials. If $pw is empty, Net::LDAP throws an error, but if it is
non-empty, it performs an LDAP bind with an empty DN and the password
provided by the user. If the LDAP server accepts this bind, the user
is logged in.
To fix this, `auth_user_dn` now dies/returns (depending on the $noerr
parameter) if the dn is falsy, which is the case for undef and the
empty string.
The issue was originally reported by forum user ITKR [0].
[0] https://forum.proxmox.com/threads/128788/
Suggested-by: Dominik Csapak <d.csapak@proxmox.com>
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Errors like permission denied or I/O ones should bubble up, otherwise
it might hide serious issues and seemingly continue to work, with a
wrong state or the like.
One could argue that the case for not existent should return undef,
while an empty file should return an empty string, but for that we
might want to check all use-sites first.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this should not be needed anymore since we can now use a simple array
in the api instead
Acked-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
enables section configs in the style of:
----
type: id
property value
property value2
property value3
----
can be combined with property strings
the provided create and update schema just pass through the array type
to the api, so the api call must always contain the complete array
also adds a test case for such array fields
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
a few things were missing for it to work:
* on the cli, we have to get the option as an array if the type is an
array
* the untainting must be done recursively, otherwise, the regex matching
converts an array hash into the string 'ARRAY(0x123412341234)'
* JSONSchema::parse_config did not handle array formats specially, but
we want to allow to specify them multiple time
* the biggest point: in the RESTHandler, to be compatible with the
current gui behavior, we have to rewrite two parameter types:
- when the api defines a '-list' format for a string type, but we get
a list (because of the changes in http-server), we join the list
with a comma into a string
- when the api defines an 'array' type, but we get a scalar value,
wrap the value in an array (because for www-form-urlencoded, you
cannot send an array with a single value) add tests for this
behavior, some of which we want to deprecate and remove in the
future
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This makes the description consistent with the other places that
have bwlimit as a parameter as well.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
its use was dropped with qemu-server 7.2-7 which we already
have a 'Breaks' entry for, so no bump required there
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
It's not just a build-dependency. Noticed during an sbuild of
qemu-server that would fail with, because it couldn't locate the
AnyEvent module used in RESTEnvironment.pm.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reduce wasting vertical space for both, the command description and
the property description, just print the respective text at the next
line, with no extra empty line in between.
For better visual command separation color would help more.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
According to rfc2986 the only valid version is 0. No newer rfc changed
that.
See section 4.1:
https://www.rfc-editor.org/rfc/rfc2986#section-4.1
Manually verifying the CSR with openssl results in the following error:
```
$ openssl req -in bad.csr -text -noout
Certificate Request:
Data:
Version: Unknown (2)
```
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
with a rough check and a slight amount of hope that nothing else in
the module dependent on turning that off for the whole module
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
to please perlcritic's highest severity level and as it makes just
sense to contain such things to the smallest possible scope.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
I assumed that the 'priv' and 'pub' RESTEnvironment types always
contained an AnyEvent eventloop, but this is actually not the case in
pvestatd and pvescheduler.
But it depended on the used model that AnyEvent used (and auto
detected) if this wrong assumption worked or not. With the
AnyEvent::Impl::Perl there weren't any problems and it seemingly
worked by accident, but when using AnyEvent::Impl::EV (which is
autodetected and used when libev-perl is installed) it interfered
with our SIG_CHLD handlers and only ever called them once. (Not clear
why this happens, maybe because AnyEvent is not setup correctly).
This patch uses $AnyEvent::MODEL as a detection instead since this is
`undef` until the first AnyEvent watcher is created, which should be
only the case where we really use AnyEvent, such as pveproxy and
pvedaemon.
Fixes: 6870afa ("RESTEnvironment: better SIGCHLD handling in AnyEvent event loop")
Link: https://lists.proxmox.com/pipermail/pve-devel/2023-March/056057.html
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
print_errs (which is also called internally by die_now) will only
'warn' the collected error stack if the log level is set to tracing.
otherwise, it will just return the error message(s) corresponding to
the error stack as string.
while they are not always the most user-friendly ones, they do
provide additional context that might help to find out what is
actually causing a particular failure. both helpers here actually
provide a meaninful user friendly context (via $msg) as final line.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
[ T: resolve merge conflict due to dropped warn helper ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This is a pattern that can be found often in Proxmox VE's API stack,
so implement it centrally here for re-use.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
when we're in an API server that uses AnyEvent, we must postpone
the worker_reaper, since it calls 'active_workers' which might already
be called and then we're inside the lock twice (flocks are per process
for us, see PVE::Tools::lock_file)
This resulted in an error like this:
close (rename) atomic file '/var/log/pve/tasks/active' failed: No such file or directory
We use the fact that only 'pub' and 'priv' RESTEnvironment types are an
api server with anyevent. For other types we call it like before.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
