3

I am trying to understand what the precedence and combination of the permission options set in fstab when mounting a disk with those that are associated with each file on disk in the case of ext4 being the file-system in use.

More specifically:

  • exec and executable flag
  • suid and suid flag
  • dev
  • defaults vs nothing at all

For instance does rw in fstab mean that the files will have read and write permissions when mounted? What will happen if they have only read associated with the file? Do the mount options affect the permissions of the mounted files as stored on on disk? Or do they filter them out somehow keeping only what is allowed in both? What happens to files newly created on the mounted disk?

There are many different articles out there, about linux permissions particular subject, but none of those I stumbled upon tackles the issue in its entirety.
If someone has a link to such an article it would be very nice to share it!

Angelos Asonitis
  • 433

3 Answers3

3

The mount options do not change the mode of the file. But can remove a permission. E.g noexec stops execution of file-files (not directories), nosuid nullifies the effect of setuid bits, nodev stops dev files from working, readonly stops writing. Mount options apply to the whole mount. And never add permissions.

“keeping only what is allowed in both” — from your question, this phrase sums it up.

I think that @steves answer is better than mine, except:

Or do they filter them out somehow keeping only what is allowed in both?

Yes it is the minimal subset of the two.

What happens to files newly created on the mounted disk?

If you have write permission and rw mount option, then files are written normally. You can still create a device file even when mounted nodev. It is just that they will not work as device files. Same for setuid, exec, etc.

ctrl-alt-delor
  • 27,993
  • Thank you very much for your answer! I wanted to mark both answers but only one is allowed. In any case, using information from both the question is definitely answered! – Angelos Asonitis Jul 16 '16 at 16:42
2

For instance does rw in fstab mean that the files will have read and write permissions when mounted?

It means that the filesystem will be mounted read/write, with access subject to file permissions after that. If you mount readonly then absolutely nothing can write to the files, regardless of permissions.

What will happen if they have only read associated with the file? Do the mount > options affect the permissions of the mounted files as stored on on disk?

If a user only has read permission, they'll only get read access. Regardless of whether you mount readonly or readwrite.

Or do they filter them out somehow keeping only what is allowed in both?

Mount option applies first, and then file permissions.

What happens to files newly created on the mounted disk?

If you've mounted a filesystem readonly, no users can create files in there.

If you've mounted a filesystem readwrite, then users can create files subject to permissions in there.

ctrl-alt-delor
  • 27,993
steve
  • 21,892
1

Mount options don't affect the stored permissions bits, but they affect the effective permissions. For example, it's possible to have a file with execute permissions (i.e. chmod a+x myfile has succeeded, ls -l shows the file having execute permissions, etc.), but if the filesystem is mounted with the noexec option, then attempting to execute the file results in a “permission denied” error. Similarly the ro option causes any attempt to write to fail, the nodev option causes any attempt to access a device to fail (even though devices can be created), and the nosuid option causes any attempt to execute a file to ignore the setuid and setgid bits.

Another way to put it is that the algorithm to decide whether a file operation is allowed goes something like this:

  1. If write permission is needed and the filesystem is mounted ro, deny immediately.
  2. If execute permission is needed and the filesystem is mounted noexec, deny immediately.
  3. If the file is a device and the filesystem is mounted nodev, deny immediately.
  4. If the file's user is one of the groups of the process attempting access, allow or deny based on the user permission bits stored in the filesystem.
  5. If the file's group is one of the groups of the process attempting access, allow or deny based on the user permission bits stored in the filesystem.
  6. Allow or deny based on the “other” permission bits stored in the filesystem.

(I simplified to show only the most important parts for our purposes here. Other considerations include access control lists, extended attributes such as immutable and append-only, and security modules such as SELinux and AppArmor. The ultimate complete and accurate — but not easy-to-read — reference would be the source code, e.g. the may_open function in the Linux kernel.)

And the setuid/setgid determination is not done (the setuid/setgid bits from the file metadata are not taken into account) if the filesystem is mounted nosuid.

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
  • Thank you very much for your answer. The only think I wanted to ask, is when you say "you simplified to show the most important parts", what are the parts that you skipped? I would love to see the whole algorithm, if possible. Because, I sincerely lack a "total overview" of this mechanism in linux and thus I am forced to over-allow certain actions in order to achieve what I am after. If you have a full overview of this exact algorithm in some form or a link to some other article please share! – Angelos Asonitis Jul 17 '16 at 10:01
  • 1
    @AgelosAssonitis The full version would be very complex — it would have to explain things like SELinux. I've added a few common ones in my answer. You can easily see some of them in the may_open function, for example the nodev flag (MNT_NODEV) blocking character and block devices (S_IFCHR, S_IFBLK), and the -a append-only flag a bit further down. The ro flag is handled in the sb_permission function, etc. – Gilles 'SO- stop being evil' Jul 17 '16 at 19:32