[pve-devel] applied: [PATCH v2 common] ticket: raise UNAUTHORIZED not FORBIDDEN in verify subs

Wolfgang Bumiller w.bumiller at proxmox.com
Fri Dec 15 12:55:44 CET 2017


applied

On Fri, Dec 15, 2017 at 06:41:49AM +0100, Thomas Lamprecht wrote:
> In the ticket and CSRF prevention token verification methods we used
> a raise_perm exception to tell our caller about a failure of such a
> verification. raise_perm uses HTTP_FORBIDDEN (403) as code.
> 
> Earlier, all such exceptions or die's where caught when the anyevent
> http server called the auth_handler method and transformed to
> HTTP_UNAUTHORIZED (401).
> 
> With commit d8327719e353198a1dffad88c246fee065054a6b from
> pve-http-server we gained the ability to tell a client about a server
> internal 5XX error, so that clients do not get wrongly logged out if
> we have a internal error.
> This resulted also in the effect that the exceptions of the
> verify_rsa_ticket and verify_csrf_prevention_token sub methods where
> passed to the client.
> 
> If an old, now invalid, ticket was sent to the server a client got
> 403 (FORBIDDEN) instead of the 401 (UNAUTHORIZED) - which he was used
> to, and thus meant that he did some wrong doing, instead of knowing
> that he just needs to login.
> 
> As we are not yet logged in here, and thus cannot possibly know if
> the call is forbidden or not, HTTP_FORBIDDEN seems the wrong code.
> Change it to HTTP_UNAUTHORIZED, which restores it to the code we told
> API clients since ever and is the correct one here.
> 
> Also RFC 2068 section 10.4.4 [1] defines that for the afformentioned
> verify methods FORBIDDEN was not really correct:
> 
>  > 403 Forbidden
>  >
>  >    The server understood the request, but is refusing to fulfill it.
>  >    Authorization will not help and the request SHOULD NOT be
>  >    repeated. [...]
> 
> With a invalid ticket or CSRF prevention token we have a
> authorization problem for the current call, not a permission problem
> (we may have, but we can't tell yet).
> 
> [1] https://tools.ietf.org/html/rfc2068#section-10.4.4
> 
> Signed-off-by: Thomas Lamprecht <t.lamprecht at proxmox.com>
> ---
> 
> changes v1 -> v2:
> * fix forgotten change to import raise not raise_perm_exc now, was
>   unseen as it was imported by our users (AnyEvent) and thus I did
>   not saw an error...
> 
>  src/PVE/Ticket.pm | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/src/PVE/Ticket.pm b/src/PVE/Ticket.pm
> index 68ea285..e9f8e3f 100644
> --- a/src/PVE/Ticket.pm
> +++ b/src/PVE/Ticket.pm
> @@ -9,10 +9,12 @@ use MIME::Base64;
>  use Digest::SHA;
>  use Time::HiRes qw(gettimeofday);
>  
> -use PVE::Exception qw(raise_perm_exc);
> +use PVE::Exception qw(raise);
>  
>  Crypt::OpenSSL::RSA->import_random_seed();
>  
> +use constant HTTP_UNAUTHORIZED => 401;
> +
>  sub assemble_csrf_prevention_token {
>      my ($secret, $username) = @_;
>  
> @@ -38,7 +40,8 @@ sub verify_csrf_prevention_token {
>  	    ($age < $max_age);
>      }
>  
> -    raise_perm_exc("Permission denied - invalid csrf token") if !$noerr;
> +    raise("Permission denied - invalid csrf token\n", code => HTTP_UNAUTHORIZED)
> +	if !$noerr;
>  
>      return undef;
>  }
> @@ -90,7 +93,8 @@ sub verify_rsa_ticket {
>  	}
>      }
>  
> -    raise_perm_exc("permission denied - invalid $prefix ticket") if !$noerr;
> +    raise("permission denied - invalid $prefix ticket\n", code => HTTP_UNAUTHORIZED)
> +	if !$noerr;
>  
>      return undef;
>  }
> -- 
> 2.11.0




More information about the pve-devel mailing list