Linux: How to prevent a file backed memory mapping from causing access errors (SIGBUS etc.)?

1
votes

I want to write a wrapper for memory mapped file io, that either fails to map a file or returns a mapping that is valid until it is unmapped. With plain mmap, problems arise, if the underlying file is truncated or deleted while being mapped, for example. According to the linux man page of mmap SIGBUS is received if memory beyond the new end of the file is accessed after a truncate. It is no option to catch this signal and handle the error this way.

My idea was to create a copy of the file and map the copy. On a cow capable file system, this would impose little overhead.

But the problem is: how do I protect the copy from being manipulated by another process? A tempfile is no real option, because in theory a malicious process could still mutate it. I know that there are file locks on Linux, but as far as I understood they're either optional or don't prevent others from deleting the file.

I'm asking for two kinds of answers: Either a way to mmap a file in a rock solid way or a mechanism to protect a tempfile fully from other processes. But maybe my whole way of approaching the problem is wrong, so feel free to suggest radical solutions ;)

1
linuxmmap
Don't try to protect yourself against root, or other users/processes with privileges greater or equal to yours. It never works. - that other guy
I see your point, root etc. are invincible. I'd like to protect myself from other processes that have the same privileges as my process. I know that from the kernel side there are no technical reasons why this shouldn't be possible. The question is if it is implemented and available to userspace. - le_me
Linux is far too flexible for this. You can for example unlink the file so that it's no longer accessible via the fs, but given the privileges a process can inspect your open FDs, clone one, and start messing with the inaccessible file. You can read the entire file into memory so you no longer depend on it, but a process can attach and start messing with your memory space. If I can suggest a radical solution, it's to follow the Unix philosophy of allowing the user to shoot themselves in the foot if they really, truly want to. If chmod 000 doesn't stop them, they consent. - that other guy

1 Answers

1
votes

You can't prevent a skilled and determined user from intentionally shooting themselves in the foot. Just take reasonable precautions so it doesn't happen accidentally.

  • Most programs assume the input file won't change and that's usually fine
  • Programs that want to process files shared with cooperative programs use file locking
  • Programs that want a private file will create a temp file, snapshot or otherwise -- and if they unlink it for auto-cleanup, it's also inaccessible via the fs
  • Programs that want to protect their data from all regular user actions will run as a dedicated system account, in which case chmod is protection enough.

Anyone with access to the same account (or root) can interfere with the program with a simple kill -BUS, chmod/truncate, or any of the fancier foot-guns like copying and patching the binary, cloning its FDs, or attaching a debugger. If that's what they want to do, it's not your place to stop them.