Trjtdtk

I believe that the FAT32 file system does not support file permissions, however when I do ls -l on a FAT32 partition, ls -l shows that the files have permissions:

-rw-r--r-- 1 john john 11 Mar 20 15:43 file1.txt
-rw-r--r-- 1 john john 5 Mar 20 15:49 file2.txt

Why is ls -l displaying the permissions of files?

The filesystem as stored on disk doesn't store file permissions, but the filesystem driver has to provide them to the operating system since they are an integral part of the Unix filesystem concept and the system call interfaces have no way of presenting that the permissions are missing.

Also consider what would happen if a file didn't have any permission bits at all? Would it be the same as 0777, i.e. access to all; or the same as 0000, i.e. no access to anyone? But both of those are file permissions, so why not show them? Or do something more useful and have a way to set some sensible permissions.

So, the driver fakes some permissions, same ones for all files. The permissions along with the files' owner and group are configurable at mount time. These are described under "Mount options for fat" in the mount(8) man page:

Mount options for fat

(Note: fat is not a separate filesystem, but a common part of the msdos, umsdos and vfat filesystems.)

uid=valueandgid=value

Set the owner and group of all files. (Default: the UID and GID of the current process.)

umask=value

Set the umask (the bitmask of the permissions that are not present). The default is the umask of the current process. The value
is given in octal.

dmask=value

Set the umask applied to directories only. The default is the umask of the current process. The value is given in octal.

fmask=value

Set the umask applied to regular files only. The default is the umask of the current process. The value is given in octal.

Note that the permissions are presented as masks, so the final permissions are the negation of the mask. fmask=0133 would result in all files having permissions 0644, or rw-r--r--.

Also, the defaults are inherited from the process calling mount(), so if you call mount from the command line, the shell's umask will apply.

But the files do have permissions. User john has RW access, while some random user only has read access. These permissions didn’t come from the filesystem itself but rather from mount options (-o uid/gid/umask), which doesn’t make them any less real.

You could have multiple vfat partitions mounted with different options and you could use ls to determine what those options were. You could even use mount --bind to have a single directory contain files from different vfat partitions, and ls would correctly show what permissions have been specified for each file.

ls doesn't know about FAT32, it only knows about the Virtual Filesystem (VFS) interface exposed by the kernel with POSIX open / readdir / stat system calls.

Linux doesn't support the concept of files that don't have user/group/other permission bits, struct stat simply contains a mode_t st_mode; member (and uid, gid members) that the kernel must fill out when ls -l makes stat(2) system calls.

There's no special code that means "not available" or "not applicable" for any of those fields, so the kernel's vfat driver must make something up. FAT16/FAT32 does have a read-only flag, but otherwise the owner/group come from mount options, and so does a umask.