Yes, this is likely a code smell, which would lead to unmaintainable code that is difficult to understand and that has a lower chance of being easily re-used. 

As other posters have noted *context is everything* (don't go in heavy-handed if it's a one off or if the practice has been acknowledged as deliberately incurred technical debt to be re-factored later) but broadly speaking if there is a parameter passed into a function that selects specific behaviour to be executed then further step-wise refinement is required; Breaking up this function in to smaller functions will produce more highly cohesive ones.

So what is a highly cohesive function? 

It's a function that does one thing and one thing only. 

The problem with a parameter passed in as you describe, is that the function is doing more than two things; it may or may not check the users access rights depending on the state of the Boolean parameter, then depending on that decision tree it will carry out a piece of functionality. 

It would be better to separate the concerns of Access Control from the concerns of Task, Action or Command.

As you have already noted, the intertwining of these concerns seems off.

So the notion of Cohesiveness helps us identify that the function in question is not highly cohesive and that we could refactor the code to produce a set of more cohesive functions.

So the question could be restated; Given that we all agree passing behavioural selection parameters is best avoided how do we improve matters? 

I would get rid of the parameter completely. Having the ability to turn off access control even for testing is a potential security risk. **For testing purposes either [tag:stub] or [tag:mock] the access check to test both the access allowed and access denied scenarios.**

Ref: [Cohesion (computer science)][1]


 [1]: http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29