This fixes the error:
unknown permission test at /usr/share/perl5/PVE/RPCEnvironment.pm line 536. (500)
which occurred when trying to create or update a notification target.
The cause was a permission 'check' parameter for the API handlers
which was nested one level too deep by accident.
This regression was introduced in a previous commit which raised the
needed permissions for notification target management. It likely went
unnoticed because the permission check is skipped for root@pam, so the
error occurs only if using another user.
Reported in the community forum:
https://forum.proxmox.com/threads/158101
Fixes: a3fe9c54 ("api: notifications: require powerful privileges for target management")
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
[ TL: minor commit message touch ups ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
These allow one to indirectly access resources from the POV of the
Proxmox VE cluster nodes. While gotify is relatively harmless, smtp
could already cause more problems to admins that are not aware of the
implications of allowing users to add targets while having some open
smtp relay that is only accessible from networks the PVE nodes can
access but not the user that can talk with PVE's API. The webhook one
is then pretty much free-form and might cause some adverse effects in
environments that are only loosely guarded, and while that might point
at general security problems, it's likely that admins will still place
the blame at our projects.
So while the former should not be problematic, the new not yet fully
released webhooks could have some impact. That said, it currently
requires Mapping.Modify, which is a intermediate powerful level priv,
so it's not like any user could use this. Still, hedging for the
safer side here seems the better choice for now, we still can open
this up if there's user feedback and we deem it safe enough doing so.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
These just call the API implementation via the perl-rs bindings.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-By: Stefan Hanreich <s.hanreich@proxmox.com>
The get_targets API endpoint is now implemented in Rust.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-By: Stefan Hanreich <s.hanreich@proxmox.com>
This new API route returns known notification metadata fields and
a list of known possible values. This will be used by the UI to
provide suggestions when adding/modifying match rules.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
'disable' can be set to disable a matcher/target.
'origin' signals whether the configuration entry
was created by the user or whether it was built-in/
built-in-and-modified.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
The Perl part of the API methods primarily defines the API schema,
checks for any needed privileges and then calls the actual Rust
implementation exposed via perlmod. Any errors returned by the Rust
code are translated into PVE::Exception, so that the API call fails
with the correct HTTP error code.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Since the target does not require Mapping.Use, it should also be
visible and testable by all users.
Short explanation why the 'mail-to-root' is exempt from priv checks:
To ensure backwards compatibility, the 'mail-to-root' target does not
require the `Mapping.Use` privs. This is needed due to the fact that
this target is used as a fallback in case no other target is
configured for an event. For instance, the /node/<name>/apt/update API
call only requires Sys.Modify for the node, but it can also send a
notification. If we were to require Mapping.Use, we could break the
apt/update API compat in the case that a notification shall be sent,
but without any configured notification target (which will then
default to 'mail-to-root').
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Check notification targets configured in datacenter.cfg and jobs.cfg,
failing if the group/endpoint to be removed is still in use there.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
The API call returns all entities that can be used as notification
targets (endpoints, groups). Only targets for which the user has
appropriate permissions are returned.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
The Perl part of the API methods primarily defines the API schema,
checks for any needed priviledges and then calls the actual Rust
implementation exposed via perlmod. Any errors returned by the Rust
code are translated into PVE::Exception, so that the API call fails
with the correct HTTP error code.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
The Perl part of the API methods primarily defines the API schema,
checks for any needed priviledges and then calls the actual Rust
implementation exposed via perlmod. Any errors returned by the Rust
code are translated into PVE::Exception, so that the API call fails
with the correct HTTP error code.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
The Perl part of the API methods primarily defines the API schema,
checks for any needed priviledges and then calls the actual Rust
implementation exposed via perlmod. Any errors returned by the Rust
code are translated into PVE::Exception, so that the API call fails
with the correct HTTP error code.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
The Perl part of the API methods primarily defines the API schema,
checks for any needed priviledges and then calls the actual Rust
implementation exposed via perlmod. Any errors returned by the Rust
code are translated into PVE::Exception, so that the API call fails
with the correct HTTP error code.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
This commit adds a new Perl module, PVE::API2::Cluster::Notification.
The module will contain all API handlers for the new notification
subsystem.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
