1

Consider the following pattern:

const int defaultBufferSize = 4096;
var stream = new FileStream(
    Path.GetTempFileName(),
    FileMode.Create, FileAccess.ReadWrite, FileShare.None,
    defaultBufferSize,
    FileOptions.DeleteOnClose);

Does the runtime or any operating system guarantee that created temporary file can never be accessed from an external unprivileged process? If so, does that fact make it pointless to manually encrypt the file?

piedar
  • 2,599
  • 1
  • 25
  • 37
  • Use permissions to block access, not R/W and DeleteOnClose file properties. If you're talking about preventing this http://stackoverflow.com/a/11060322/495455 then I assume so, that's something you can easily test. – Jeremy Thompson Jan 21 '17 at 03:32
  • If you do not want to give access to anyone, then the FileShare.None would prevent anyone else from opening the same file. Declines sharing of the current file. Any request to open the file (by this process or another process) will fail until the file is closed. So if your goal is to create and use the temp file and then delete it and do not want anyone else to read from this file, then FileShare.None is the right approach. – Venki Jan 21 '17 at 03:34
  • Explain your scenario. It depends who you're trying to protect the data from. If you're trying to protect data from the user, then that user has different ways of obtaining your data. Either through sniffing network traffic, or by installing a file system filter driver that intercepts all data written to disk. – CodeCaster Jan 23 '17 at 15:15
  • @CodeCaster I know there's no point trying to protect anything from a local administrator or root user. I'm not so much asking "is it secure enough?", but just "how secure is it?" I'm also interested in how reliable these file flags are across operating systems and CLR implementations. – piedar Jan 23 '17 at 16:02

0 Answers0