ASP/ASP.NET Best way to handle write permissions?

First let me start by saying, I'm a pretty big believer that there is almost always a better solution than writing stuff out to disk. Whether it's writting the data to a database, or feeding web services, writing out to disk should be the last option.
That being said there are some valid reasons, but this is sort of tricky and dependent on why the app needs to write out the files.

Having the data written outside of where code is running from is an absolute requirement. Allowing end users to write to a path where the ASPX/asp engines can interpret/execute code is bad for obvious reasons.

Some other things that impact this are:

1. Whether you're running the worker process under a domain account or the standard network service. It's important to realize that when you grant the IIS_WPG group write access to a folder, any ASP.NET application running under the default account on the server may write files to that folder. This is a less than ideal configuration on servers where muliple applications run especially when the applications are untrusted and/or running in an ISP/shared hosting environment.
2. Whether the generated files need to be web available or not. If your application is just writting out some non-web viewable files, simply creating the directory, granting the rights, and configuring the application to read/write to the correct place is all you need. If the application needs to write out web viewable files, (this comes up fairly commonly in content management scenarios) you need to create a virtual directory (without execute code/scripts rights) that maps to your writable directory.
3. Whether or not you're working in a load balanced / web farm environment. If your application is operating in a farmed environment and needs to write files to disk for some reason, you're presented with a whole new problem. How do you keep user generated files on webserver1 in sync with the files generated on webserver2? Doing it via some convoluted syncronization script is painful at best and riddled with race/syncro issues. The best way of implementing this is to create a share on a third server (idealy a cluster with some redundancy) and store the data there. If you're running your worker processes under domain accounts (Security Best Practice), you can even map to the share in the application without having a user/pass anywhere in the code or web.config (makes audit/security people happy). IIS also has the ability to map virtual directories to UNC paths, so this won't impact your ability to make this content web viewable.

The App_Data Folder

To improve the security of the data used by your ASP.NET application, a new subfolder named App_Data has been added for ASP.NET applications. Files stored in the App_Data folder are not returned in response to direct HTTP requests, which makes the App_Data folder the recommended location for data stored with your application, including .mdf (SQL Server Express Edition), .mdb (Microsoft Access), or XML files. Note that when using the App_Data folder to store your application data, the identity of your application has read and write permissions to the App_Data folder.

What's new in ASP.NET Data Access

Probably betting to look over on stackoverflow.com...

Best practice is to put that folder OUTSIDE of your document root and have your app read from the file system. Otherwise, make the folder read-only except to the ASP[.NET] user and control the write priviliges with your app's internal authorizations.

App_Data is, by default, writable but not readable. The server seems to resist any attempt to change this. Thus, it is better to make a completely new folder and change the permissions on it to NOT EXECUTABLE and READABLE and WRITABLE.