Some of these issues may depend on the OS that is running the web server... the following points are valid for unix-like systems.

If the web-server user account does not have write access on the DOCUMENT_ROOT directory (and if you don't have the ability to change that), then you can't use a CGI script to create, rename or delete files there. If a file exists and the web-server user account has write access on that, it can modify that file's contents (e.g. open for read/write access, or open once to read it, close it, and open it again to write it). But then you need to pay attention to file locking, so that concurrent web clients don't mess things up by trying to modify the same file at the same time.

If you (as "normal" login user) can create a directory in DOCUMENT_ROOT, you should be able to control the group ownership and permissions on that directory so that your CGI script (running under the web-server user account) can create, delete, rename, and modify files at will in that directory. Even there, you need to be careful about how the CGI script sets up file names, opens files for i/o, etc -- taint checking is a must.

In general, limiting that sort of CGI activity to a specific subdirectory is cleaner, safer, and easier to maintain. Meanwhile, setting up a CGI script that does a "setuid" (change user identity) to circumvent standard protections on the DOCUMENT_ROOT directory is a bad, risky, messy idea. It might be doable (probably requires some root/sysadmin intervention), but I would strongly advise avoiding that approach.