Hacker News new | ask | show | jobs
by meonkeys 679 days ago
I attended a Tanenbaum lecture once where he talked about how silly it was that nothing happens if permissions are reduced for a file while some other user/process has an open handle to it, and this is something Linux doesn't care to handle and MINIX does (or perhaps just that a kernel/filesystem should handle it, and few do -- I don't recall exactly). Surely an edge case (logging? what else? I never keep files open for too long), but I thought it was an interesting one.

You can test this in Bash: userA does cat>/tmp/newfile (assuming a chmod or relaxed umask so /tmp/newfile is created with permissions 0664), userA types in lines of text every few seconds, userB does tail -f /tmp/newfile and watches lines appear, then userA does chmod 600 /tmp/newfile, but userB can continue to tail -f /tmp/newfile and watch lines appear.

3 comments

Yes, it's the equivalent of "perimeter security" in networking. Once you are inside accessing a resource (connected to a network node or reading from a file descriptor in the kernel), you don't lose that access.
The existing pattern leads to very useful usecases though: there are resources a server only needs to open once (e.g. during startup), and being able to then remove access while holding onto the one handle you're going to use is a security win.
How would you want memory-mapped files to work, if permission changes affected open files?
You could synchronously invalidate the PTEs corresponding to the mapper pages on chmod and let the soft fault handler re-evaluate pages when next accessed.

That said, Linux gets this right, and Tanenbaum gets it wrong. Preserving access rights requested on open makes the system easier to reason about.

You could but it would induce corruption in programs. Programs expect I/O to fail much more often than they expect memory accesses to fail.
Programs using mmap have to be prepared for SIGBUS on mapped region access anyway --- consider the surprise removal (yanking out USB stick) case.

That few programs, especially native code ones, bother to make themselves robust against this failure mode of mmap doesn't make it any less part of the mmap contract between the kernel and userspace.

Contracts are one thing, reality is something else though.