PhysicalFileProvider can't find ".env" file

[HaoK]

Maybe files that start with .causing issues?

Found by aspnet/Configuration#505

Simple repro:

        [Fact]
        public void CanAddDotEnvFile()
        {
#if NET451
            _basePath = AppDomain.CurrentDomain.GetData("APP_CONTEXT_BASE_DIRECTORY") as string ??
                AppDomain.CurrentDomain.BaseDirectory ??
                string.Empty;
#else
            _basePath = AppContext.BaseDirectory ?? string.Empty;
#endif

            File.WriteAllText(Path.Combine(_basePath, "works.env"), "foo");
            Assert.True(File.Exists(Path.Combine(_basePath, "works.env")));
            Assert.True(new PhysicalFileProvider(_basePath).GetFileInfo("works.env").Exists);

            File.WriteAllText(Path.Combine(_basePath, ".env"), "foo");
            Assert.True(File.Exists(Path.Combine(_basePath, ".env")));
            Assert.True(new PhysicalFileProvider(_basePath).GetFileInfo(".env").Exists); // Failes
        }

[natemcmaster]

This is expected behavior. #51 cc @glennc

[atrauzzi]

If I dig a little after #51, it specifically references globbing. I am not globbing.

My use case is that I'm explicitly trying to load the file. I shouldn't lose access to files that start with .. The only automatic behaviour you should really want is to not have them included in non-verbose/non-all directory listings.

Otherwise, they're just files like any other.

[natemcmaster]

I don't have context on the original design decisions. Changing current behavior could be an issue. For now, users can workaround by using System.IO directly.

cc @muratg That said, it's worth revisiting this behavior. This is not the first time the issue has been raised. IMO the necessity of dropping out to System.IO indicates a problem in the abstraction.

[muratg]

@natemcmaster Agreed. We should look into this in 2.0 and reconsider the behavior.

[atrauzzi]

Is fixing this in 1.* really that big of a regression? I know there would be some component of assumption, but the current behaviour is fairly inconsistent with expectations on platforms that do support dot-files.

Would stand to reason more people are being blindsided by current behaviour than those who are intentionally relying on it.

[muratg]

@atrauzzi more than the concern of a regression, I'm slightly more worried about the security implications. If you don't know this behavior has changed, you may inadvertently start serving files that you don't want to.

cc @blowdart, @glennc

[atrauzzi]

I suppose that's a possibility, although "files that start with a dot are secure" is not something I'd say is true enough to need to stick to. The implementation in that case will have lead people to a bad assumption.

"Files that start with a dot" are simply exempt from globbing/bulk operations. So the idea that there's a security angle here assumes the security analysis done earlier was correct. It only compounds the error to assume that the behaviour needs to be preserved.

Worth remembering throughout: I'm only looking for a single file, not a glob. Might be a way to address it in 1.x by making the distinction that way?

[blowdart]

There's a convention around . directory & files that they're not included in normal operations, be they github checkins, or, well, anything else. It's not saying they're secured, just that there's an assumption they're ignored. Hence the security concern.

[HaoK]

There's a convention around . directory & files that they're not included in normal operations, be they github checkins, or, well, anything else. It's not saying they're secured, just that there's an assumption they're ignored. Hence the security concern.

It's one thing to ignore them in most operations. It's another to block explicitly reading them when you want. Given that IFileProvider is the abstraction for reading files. The equivalent would be if File.Read didn't let you open .env files. Kinda broken.

[blowdart]

True. If you could fix it, but ensure the static file provider didn't serve them, and it didn't serve them if they were hidden/system that would mollify my concerns. What about excluding them from directory listings too?

[HaoK]

True. If you could fix it, but ensure the static file provider didn't serve them, and it didn't serve them if they were hidden/system that would mollify my concerns. What about excluding them from directory listings too?

Well the logic for not serving . Files can live in the static file handler. That kind of check shouldn't go in the low level file abstractions layer of GetFileInfo since we end up using that for reading config files (which we should allow and is currently blocked as a result)

[blowdart]

Sure, but both would need updated at the same time.

[pranavkm]

We could separate the two concerns - have a regular PhysicalFileProvider and a SafeToServePhysicalFileProvider which we use in StaticFiles and such.

[blowdart]

StaticFiles already makes decisions based on extension doesn't it?