Permissions aren't the issue (as long as your users can't modify the script you're letting them run). The whole point is that if they control-C out of the script, they fall back to a login prompt; not to a shell prompt.

What you have to be careful about is any interactive commands that you let your users access from your script. For instance, if you let them use ed, ex, sed, or vi to edit a file, they can get a shell escape from those editors to run anything they want (including an unrestricted shell). Some editors have an option to restrict the ability to do this, but these options are not standardized (so you need to check the man page for any editor you want to allow your users to use for an option such as -r or a command name like red or rvim that will start the editor you want your users to use in restricted mode on your system).

If you want to see a very simple example, create a new user with login name date with or without a password. Set the login shell for that user to the path to the date utility on your system (probably /bin/date or /usr/bin/date). When someone logs in to your system using the login name date, they'll see the current date and immediately go back to a login prompt.

Just remember that since you didn't login with bash, or ksh, or some other normal shell, the initialization scripts those shells run when you login are not run. So, your script will need to initialize any environment variables it needs to run just like you need to do if you run a script from a cron job.