1

I have a doubt on what the entry created in the Open File Table upon calling open() contains.

The following schema

bytebytego linux descriptor illustrated

from bytebytego seems quite good to understand the big picture of opening a file, but in the Open File Table I see nothing about file permissions (which are only depicted in the inode at the bottom).

This source instead says:

The open file table contains several pieces of information about each file:

  • the current offset (the next position to be accessed in the file)
  • a reference count (we'll explain below in the section about fork())
  • the file mode (permissions),
  • ...

Since the file permissions are stored on disk in its inode, if the last source I mentioned is right, does it mean that the permissions are copied in the entry of the Open File Table ? And if so, maybe the schema from bytebytego omitted this detail for the sake of simplicity?

Improve this question

1 Answer 1

Reset to default
3

Yes, the permissions are copied to the open file table. More accurately, the mode is copied to the open file table; that includes both a file’s type and its permissions (see Understanding UNIX permissions and file types and What file mode is a symlink?). As far as the kernel’s use of the open file table is concerned, the permissions only matter when opening a file; after that, all it checks is the file type. This might explain why the bytebytego diagram omits the copied permissions: they don’t matter in practice (in any case, it shows a very simplified view of the data involved, which isn’t surprising because there’s a lot of data).

In the kernel, files are represented by instances of struct file, and those include a pointer to the relevant struct inode, which contains a copy of the file’s mode (including permissions). They also include the file’s mode (f_mode), which stores the flags passed to open — the kernel does check those when necessary for file operations.

If you want to follow this from a task, task_struct has a files field pointing to the open file table represented by instances of files_struct, which points to struct fdtable which leads to an array of struct file.

Improve this answer
4
  • Thanks for your answer @Stephen Kitt . What's the usage for permissions in the open file table? Are they used by the OS in some way? Commented Oct 8, 2024 at 16:44
  • 1
    The mode is used a lot (to check the file type), but once a file is opened its permissions aren’t checked again. Commented Oct 8, 2024 at 18:58
  • The fact that the inode permissions don't really matter for an already-open fd (OFD) seems a likely reason the quoted diagram doesn't include the inode permissions in the open file table entries. It does appear include "file status flags" with values of "w" and "r" -- That looks like it could be the "mode" the file was opened in? The mode of open is what works as "access control" for operations on the fd anyway. Commented Oct 8, 2024 at 20:18
  • Indeed, thanks ilkkachu — that would explain the diagram. Commented Oct 9, 2024 at 12:48

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.