0

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:

  1. 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?)

  2. 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.

3
  • 1
    That second part doesn't really make much sense, or at least you'd need to consider who is the "we" there. A process changes the permissions bits of a file, and then it's changed. The job of the OS is make that change visible to any process that cares to ask. It's also the job of the OS to take care that the change ends up in some backing storage (if there is one to begin with!). Same for reads and writes to a file.
    – ilkkachu
    Jun 22, 2022 at 18:17
  • @ilkkachu so as Marcus said, it doesn't matter how I implement it (for example using my suggestion), the important thing is that all processes see the change and don't use the old, outdated, inode?
    – Ariel Yael
    Jun 22, 2022 at 18:20
  • 1
    @ArielYael exactly, otherwise that'd be called a "race condition". Jun 22, 2022 at 18:21

1 Answer 1

1

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.

5
  • When you say "should be consistent across multiple processes", do you mean that all processes should see the same updated inode? and the way this is done doesnt matter? Also, then why when we call write on a file we opened with r (read) do we get an error, if we don't check permissions?
    – Ariel Yael
    Jun 22, 2022 at 18:11
  • a) yes b) because you opened the file such that it cannot be written to. That's got nothing to do with file permissions. Jun 22, 2022 at 18:16
  • But you do check that I'm not allowed to write with that fd, it's simply not considered "permission", right?
    – Ariel Yael
    Jun 22, 2022 at 18:18
  • no! You opened a file for reading. The file descriptor simply can't be used for writing. There's nothing to be "checked" here against anything stored. It's simply not possible. "checking" implies you look at some property of the file, then decide. But opening as r doesn't have any implication on what is stored about the file. It's really just a mode of opening. (if you want to have it in detail, as an operating system, you'd simply not fill in the "call this if something gets written to the file" kernel struct member for that file descriptor you've gotten from open.) Jun 22, 2022 at 18:20
  • 3
    The OS does need to check if the fd was open for reading or writing when a process tries to do one of those. (It has to know somehow if to proceed with the operation, or return an error.) The man page for open() calls that "access mode" and the description of the EBADF error for write() just says "fd is not a valid file descriptor or is not open for writing.". It's a check on some internal value, yes, and you could think of it as a sort of a permission check, just one on the fd, not the underlying file. But it's not usually called that.
    – ilkkachu
    Jun 22, 2022 at 18:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .