Changing file permissions in inodes while a user has the file open
According to this SO question, when we open a file to read it we only check permissions once when we open it. And if we change the permissions of the file and say the user is no longer allowed to read from the file, the user will still be able to read the file. This raises a few questions:
-
Don’t we need to keep checking permissions, since if for example we open a file to read it, and then try to use
write, shouldn’t we get an error? This means that we check what we’re allowed to do with the file. (perhaps we save locally with the fd the operations we are allowed to do with it and check them each time?) -
When we update permissions, do we update the single copy of the inode in the inode table or do we directly update the copy on the disk? Since if we update the permissions directly on the copy on the disk, other processes looking at the inode table will not see the updated version, so it makes more sense to update the inode table and from there let the OS write the changes back to the disk.
Don’t we need to keep checking permissions, since if for example we open a file to read it, and then try to use write, shouldn’t we get an error?
No, we shouldn’t! This is intended. The permissions at the point of opening the file matter, not later. That’s the API.
When we update permissions, do we update the single copy of the inode in the inode table or do we directly update the copy on the disk?
That is totally an implementation detail of the file system layer. We don’t know – and also, we mustn’t care. All we know is that this should be consistent across multiple processes, and where the change is made doesn’t matter.