My advice is, your architecture is insecure from the start so don't do it that way.

You are making a fine breeding ground for remote shell exploits if you are going to let users provide parts of the path. What happens if they put a pipe mark in there? Bad things, they can execute commands possibly.

If you really must, then perhaps you can make very sure that $username and $input{'file'} are less than say 10 characters, a..z inclusive only. Even better, scan the preset directory for files and just offer a list of files for them to select in a CGI form (see CGI.pm), instead of allowing them to create files. This way you never actually insert variables which came from the input form into your path. You also want to consider that this information is going over the network in plaintext, in fact if you use GET anyone can read it. And um, where's the password dude?

And of course you are giving a web-based program to edit a user's root directory which is also not a good idea in general and might not work without changing permissions. Much better that your program manages everything in one place, knows what it has, and only serves things to the person who has been authenticated to get them.