I don't think there is any straightforward way other than making them an admin for the process, which I'm guessing you do not want.

I can think of a couple ways to do it as a custom set-up, all of which are going to add more stuff onto your process, so it really depends on complex you are willing to make things in order to allow this functionality.  How many requests are we talking about is likely going to be your deciding factor regarding whether you want to go through the trouble or not.  Are we talking a couple requests per month or dozens of requests per day?

Idea 1 - Have your process include a parallel gateway that assigns an additional task back to the user.  This task gives them the option to cancel the process.  If they submit that cancellation task, it triggers a signal throw that all other tasks are watching for and can be interrupted by and lead to end events.  You would also need to ensure that the main flow sent a signal at its end to interrupt the waiting for cancellation task.  The benefit to this method is that everything is contained within the single process, but the downside is that each user has a form assigned to them during the entire time the process is being worked on.

Idea 2 - Have your process include a parallel gateway that runs a workflow.  This workflow checks a custom database table that you set-up to list cancelled forms (maybe by instance ID number).  The workflow runs in a loop that includes a check for the database record, a delay for some amount of time before it checks again, and then a check back to forms for a hidden field or some other indicator to determine if the main process flow is complete, and thus the workflow needs to end.  If the database lookup confirms a cancellation request, then the workflow ends.  Ending the workflow triggers a signal throw that triggers an interrupt of all running tasks - similar to what was listed in Idea 1.  Then set-up a new process in Forms that lets users select from their initiated processes (there are posts elsewhere on LFAnswers that have great tips for things like setting up a Database view that mimics the Monitor page in forms - you could use that as the basis for the user lookup of their initiated processes, limiting it to just the type(s) of process that you want to allow them to cancel) - submitting this "cancellation request" process will populate the database value to say the form needs to be cancelled, which in turn triggers the workflow to terminate, which triggers the signal throw, which triggers the interrupts and ends the process.  The upside with this is that staff don't need to have a task assigned to them at all times, they can find the cancellation when they need it.  The downside is that there are running workflows at all times that the forms processes are running.

Idea 3 - Basically the same thing as idea 4 - but add the loop and delay into Forms instead of Workflow - the Workflow checks the database and populates a value into a field in forms and then ends.  Forms in turn checks for that field value to determine whether to loop again or throw the signal.  This will be a little more foolproof than idea 2 in case the workflow terminates unexpectedly it will try again instead of just ending.  But you'd need to seriously increase the amount of time in the delay, because when you open a forms task, it checks all the historical submissions for field changes.  Even without field changes from each run of the workflow, it's still really going to slow things down havings to check hundreds or even thousands of workflow events any time you open a task in the process.

These are all kind of messy and cumbersome, so it just may not be worth it unless you are getting lots of requests for this.