Return 500 instead of 400 when temp directory isn't writeable

[M1keF]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I have just upgraded my Web App from 6.0.9 to 6.0.10 and am now getting a 400 Bad Request response when making large requests to my API. My web app is hosted on a Kubernetes container using Linux with a read-only root file system with the ASPNETCORE_TEMP environment variable to be a separate file system which is writable. If I make the root file system on the container writable then the problem does not occur.

The problem occurs when making requests which exceed 64KB and results in response below being returned to the client.

{type: "https://tools.ietf.org/html/rfc7231#section-6.5.1",…}
errors
: 
{"": ["Failed to read the request form. Read-only file system"]}
""
: 
["Failed to read the request form. Read-only file system"]
status
: 
400
title
: 
"One or more validation errors occurred."
traceId
: 
"00-c7f84b7e6c1e57951d1568eb3f94cab6-aeec3a125ea5243e-00"
type
: 
"https://tools.ietf.org/html/rfc7231#section-6.5.1"

On investigating the issue, I suspected that the problem was to do with large requests being written out to the file system and having looked into the code changes for 6.0.10 I suspect that the changes made in Use Path.GetTempFileName() for 600 Unix file mode' could be the cause.

Some of the changes have introduced calls to Path.GetTemplFileName() which creates a temporary file in the temp folder of the root file system, and if the root file system is read-only then this will be a problem. For example, the method below retrieves the temp folder location, taking into account ASPNETCORE_TEMP, but then in the case of a non-Windows platform then calls Path.GetTemplFileName() which will use the root file system.

aspnetcore/src/Http/WebUtilities/src/FileBufferingWriteStream.cs

    [MemberNotNull(nameof(FileStream))]
    private void EnsureFileStream()
    {
        if (FileStream == null)
        {
            var tempFileDirectory = _tempFileDirectoryAccessor();
            var tempFileName = Path.Combine(tempFileDirectory, "ASPNETCORE_" + Guid.NewGuid() + ".tmp");

            // Create a temp file with the correct Unix file mode before moving it to the assigned tempFileName in the _tempFileDirectory.
            if (!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
            {
                var tempTempFileName = Path.GetTempFileName();
                File.Move(tempTempFileName, tempFileName);
            }

            FileStream = new FileStream(
                tempFileName,
                FileMode.Create,
                FileAccess.Write,
                FileShare.Delete | FileShare.ReadWrite,
                bufferSize: 1,
                FileOptions.SequentialScan | FileOptions.DeleteOnClose);
        }
    }

Expected Behavior

I expect that by setting the temporary folder location via the ASPNETCORE_TEMP environment variable that all temporary files will be written to this folder, and so avoiding any errors caused by attempting to write to a read-only root file system.

Steps To Reproduce

Hopefully the code example I have shared is enough to go on to fix this.

Exceptions (if any)

I have not been able to locate any exceptions being raised for this problem - the only clue as to what the problem is is the message returned in the response 'Failed to read the request form. Read-only file system'. Maybe because the problem occurs when trying to access the form data the error is treated as being a problem with the form data supplied by the client and so the exception is caught and sent back to the client as a '400 Bad Request'.

.NET Version

6.0.402

Anything else?

ASP.NET Core 6.0.10
Azure Kubernetes 1.23.12

[Tratcher]

@halter73

[halter73]

@M1keF Can you work around this issue by setting the TMPDIR environment variable to a directory the application has write access to? Maybe it could match ASPNETCORE_TEMP.

This is a regression, so we can look at backporting a fix that doesn't write to TMPDIR, but that is probably going to require using private reflection to call unix file mode APIs @eerhardt. On the other hand, it does seem a bit unusual to be unable to write to TMPDIR. It feels like that could break a lot of things. And it seems like the workaround should be fairly straightforward.

[davidfowl]

I would like to introduce a temp file abstract that we write to that is controllable via DI that we use for these subsystems.

[M1keF]

Thanks - I can confirm that the workaround works. For my use case, it leads me to question whether it would be better to just set TMPDIR to cover all eventualities and not use ASPNETCORE_TEMP.

Something I discovered whilst testing this out is that the response returned to the client is leaking out the location of the temp folder if it doesn't exist - is there a setting to prevent this detail being returned? I would also expect a 500 Internal Server error in this case rather than a 400 Bad Request. I can raise this as a separate issue if appropriate.

{type: "https://tools.ietf.org/html/rfc7231#section-6.5.1",…}
errors
: 
{"": ["Failed to read the request form. /mnt/tmpz"]}
status
: 
400
title
: 
"One or more validation errors occurred."
traceId
: 
"00-7b8b047142c3b9c70d1106ad5f9498fe-a7a8da7c389c9047-00"
type
: 
"https://tools.ietf.org/html/rfc7231#section-6.5.1"

Thanks for your help.

[adityamandaleeka]

Having the temp directory location being configurable is tracked by an existing issue: #9466

Responding with a 400 instead of a 500 when the directory isn't set up correctly seems weird for sure. We're not sure how complex that would be to fix though.

@blowdart What is our guidance on having ProblemDetails enabled in production? In this case, that happens to reveal the temp path.

[adityamandaleeka]

@brunolins16 points out that fixing this to be a 500 will prevent the exception from being exposed. 😄

[adityamandaleeka]

Retitled this issue to track that ^

[blowdart]

@blowdart What is our guidance on having ProblemDetails enabled in production?

As it's been for 20+ years. Don't do that. If you are returning details somehow in prod by default that needs to change.

[boukisge]

We are experiencing the same issue with your docker image. Please provide assistance

[drauch]

I don't know if I should create a separate ticket for it, but as an addition:

If there is not enough disk space to read the form data (e.g., huge file upload), also a 400 is returned (incl. the not-enough-diskspace information!) instead of a plain 500.

Best regards,
D.R.