option for private files analogous to dotfiles

[coolaj86]

I don't know if this would even work because I don't know if Windows has something like this, but I'm wondering if you would be open to adding an option (or accepting a PR) to handle private files (files that do not have world-readable) in the same way that dotfiles is handled.

A public file or directory is typically mode 644 or 755

A private file or directory is typically mode 400 or 500

My suggestion is that an option like privatefiles: 'ignore' would treat any file lacking world-readable permission (the o of ugo does not have 4) the same as dotfiles: 'ignore' is currently treated.

[dougwilson]

At a base level all features should works on Linux and Windows equally (which is why we run the CI in both environments with every commit and PR). So if it's not possible to implement on Windows, then it would be a no-go on this module, at least.

As for the feature, I've never heard of such a feature before. This seems delicate because it sounds like it's intended to provide some type of security, so we'll want to ensure whatever implementation is robust. A good way to do this is to look at prior art to check existing implementations. Are there any existing implementations for this out there (for example in Apache HTTPD or NGINX)?

[kachkaev]

@coolaj86 I guess the definition of a private file can vary depending on how this or that developer interprets permissions. Your suggestion is also a bit hard to imagine on Windows.

I guess you can just run a custom test to figure out what to serve and what not to serve. E.g.:

const myCustomTest = (path) => {
  // custom logic here

  return true; // simply serve all files
}
const statics = express.static(pathToStaticDir);
server.get("*", (req, res, next) => {
  if (myCustomTest(req.path)) {
    return statics(req, res, next);
  }
  return next();
});

[coolaj86]

I think that would be great.

I also think that the default behavior should be to NOT serve (i.e. 'ignore') private files.

So, invert the reason for not making the change:

We might not want to make the change to turn foo-option on because we can't guarantee that it is meaningful on all systems.

becomes

We want to make the change to make foo-option the default because we can guarantee perfectly that turning foo-option off will loosen the restriction on all supported systems.

Reframing it this way makes it not a matter of insecurity to turn it on, but rather a matter of security to not turn it off. If in the future there is a better way to read windows ACLs, then that could be included, but no risk is introduced that wasn't there prior in either case.

I don't choose to not put a fence around my house because it isn't a war-proof, tank-proof barrier. Rather I choose to put a fence around my house because it keeps the neighbor's dog out, keeps honest people honest, and is a deterrent to creepers compared to the next house (which is the case of "I don't have to outrun the bear to avoid being eaten, I have to outrun you who will then be eaten first, thus satisfying the hunger").

[coolaj86]

bump