9

A question that occurred to me earlier: are file permissions/attributes OS- (and therefore kernel-) dependent or are they filesystem-dependent? It seems to me that the second alternative is the more logical one, yet I never heard of reiserfs file permissions, for example: only "Unix file permissions". On the other hand, to quote from a Wikipedia article:

As new versions of Windows came out, Microsoft has added to the inventory of available attributes on the NTFS file system

which seems to suggest that Windows file attributes are somehow tied to the filesystem.

Can someone please enlighten me?

Improve this question

4 Answers 4

Reset to default
8

Both the kernel and the filesystem play a role. Permissions are stored in the filesystem, so there needs to be a place to store the information in the filesystem format. Permissions are enforced and communicated to applications by the kernel, so the kernel must implement rules to determine what the information stored in the filesystem means.

“Unix file permissions” refer to a traditional permission system which involves three actions (read, write, execute) controlled via three role types (user, group, other). The job of the filesystem is to store 3×3=9 bits of information. The job of the kernel is to interpret these bits as permissions; in particular, when a process attempts an operation on a file, the kernel must determine, given the user and groups that the process is running as, the permission bits of the file, and the requested operation, whether to allow the operation. (“Unix file permissions” also usually includes setuid and setgid bits, which aren't strictly speaking permissions.)

Modern unix systems may support other forms of permissions. Most modern unix systems (Solaris, Linux, *BSD) support access control lists which allow assigning read/write/excecute permissions for more than one user and more than one group for each file. The filesystem must have room to store this extra information, and the kernel must include code to look up and use this information. Ext2, reiserfs, btrfs, zfs, and most other modern unix filesystem formats define a place to store such ACLs. Mac OS X supports a different set of ACL which include non-traditional permissions such “append” and “create subdirectory”; the HFS+ filesystem format supports them. If you mount an HFS+ volume on Linux, these ACLs won't be enforced since the Linux kernel doesn't support them.

Conversely, there are operating systems and filesystems that don't support access control. For example, FAT and variants were designed for single-user operating systems and removable media and its permissions are limited to read/read-write and hidden/visible. These are the permissions enforced by DOS. If you mount an ext2 filesystem on DOS, it won't enforce the ext2 permissions. Conversely, if you access a FAT filesystem on Linux, all files will have the same permissions.

Successive versions of Windows have added support for more permission types. The NTFS filesystem was extended to store those extra permissions. If you access a filesystem with the newer permissions on an older operating system, the OS won't know about these newer permissions and so won't enforce them. Conversely, if you access an older filesystem with a newer operating system, it won't have contain of the new permissions and it is up to the OS to provide sensible fallbacks.

Improve this answer
2
  • "The job of the kernel is to interpret these bits as permissions; in particular, when a process attempts an operation on a file, the kernel must determine [...]" Does not that mean that a kernel could in theory be altered to ignore all that and read the data anyway ? (A kind of direct disk access) Or is there something else preventing that ? Commented Apr 13, 2017 at 12:05
  • @Overmind Of course. Kernel code has access to everything. The disk doesn't know anything about processes, users or permissions. The kernel tells the disk “give me block 232876” and the disk replies with the content of the block. Determining which processes may access which blocks (or which parts of blocks) is the job of the kernel. Commented Apr 13, 2017 at 13:04
4

In order to user certain rights both the kernel and the filesystem must support them. If the filesystem does not even support the most basic access rights then the filesystem code has to fake them (e.g. with the mount option umask for vfat).

Improve this answer
3

My understanding is that the kernel implements inodes in VFS. inodes contain permission information (UNIX and ACL) along with other metadata and the filesystem can extend the inode to add features. If you're interested, read up on Linux VFS - gory stuff if you're not a systems programmer.

Improve this answer
1

As general rule, files permission and files attributes are stored into filesistem [the exact way depends on the filesystem in question (ext3/4, riser, NTFS etc ... )] but are used by the kernel, normally to enforce something.

For example The kernel in *nix like sistema is "the thing" that know the meaning of the UID associated to a file / directory. A file UID is simply a number stored alongside a certan file by the filesystem but the "translation" of such number to a certain user (and corresponding rights to do something or not ) is done by the kernel.

Improve this answer

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.