search

glpi-project / glpi

GLPI is a Free Asset and IT Management Software package, Data center management, ITIL Service Desk, licenses tracking and software auditing.
https://glpi-project.org
GNU General Public License v3.0
4.36k stars 1.3k forks source link

Webhooks need to bypass user permission checks #18404

Open cconard96 opened 2 days ago

cconard96 commented 2 days ago

The Webhook feature currently makes requests for the related data through the new API and uses the current logged in user. In most cases, this isn't an issue since whoever creates/updates something also has the ability to view that item. When webhooks get triggered from a Crontask though, the current user may be too low privileged, in another entity, or there may not be any user logged in at all in the case of externally triggered tasks.

This issue was noticed with tickets created from collected emails.

cedric-anne commented 2 days ago

Unless I miss something, there is no "current user" in a crontask context. What user is used then?

cconard96 commented 2 days ago

If no user is logged in, no user is used. The requests to the API are made directly through the router rather than making HTTP requests through curl or Guzzle. The only "authentication" that is done is through InternalAuthMiddleware where it sets the client info manually or causes the authentication process to fail if there is no logged in user.

orthagh commented 2 days ago

cf !35208

I don't know if we need a bypass (maybe yes) but we need more and more cli executions and rights checkings are locking too much in this context. more example, already identified execution of workflows. We need this before 11.0 release.

I am not sure, but as an alternative to opening the gates, we may use the SYSTEM_GLPI user for that instead, and check if can have full rights for him (it may already be the case). It will help also identify actions in logs.

cconard96 commented 2 days ago

I had two ideas when I was made aware of the issue yesterday:

  1. Use the system account as a sort of "Global Administrator". We still block actual logins with this account and prevent assigning profiles, but have a method to manually switch to a session for it and automatically grant permissions over every entity and all rights in the session itself. This would only work in separate requests (both workflows and webhooks make HTTP requests to the GLPI API).
  2. For webhooks at least, we let the administrator choose the user account that will authenticate with the GLPI API for the data via actual HTTP requests.

For workflows, we could try forcing all permission-dependent interaction through the GLPI APIs or create a bridge in the GLPI core that lets that specific feature bypass permission checks.