On Thu, Nov 10, 2016 at 02:53:14PM +0000, Lisi Reisz wrote: > Richard - are you clear that the permissions are not for the partitions but > for the directories on the mount points on the filing system on which those > partitions have been hung?? This can be hard to grasp, but it can and does > sometimes make a difference, e.g. if the same partition or device gets > mounted somewhere else. > > Being slightly older than you, Richard and coming from the pre-electronic > computer generation, I am hoping to grasp and understand the basic Unix > filing system finally some time before I keel over. (I *think* that > electronic computers are slightly older than you are.) ;-)
Well, let's see if I can shed some light here. Probably not, but I'll try. At the bottom layer of this whole thing, we've got actual hardware. The computer can make the disk retrieve ("read") or store ("write") information by modifying the voltage on various wires. The kernel knows how to tell the computer to do this (by dark magic). The kernel can, for example, read byte number 13543287 of the disk. Storing all of your information in one gigantic chunk is not always the best policy, so you have the ability to subdivide the disk into "partitions". Each partition is then treated as a separate hunk of bytes. The kernel also knows about these, and it can request byte number 9986351 of partition number 3. Even with partitions, retrieving information from a disk in this way would be terribly inconvenient for most applications, so this is almost never done. Instead, there is another layer: the file system. A disk, or a partition, can have an organizational structure laid on top of it which allows information to be stored in "files" which have names. Instead of requesting byte number 9986351 of partition number 3, you can request byte number 0 of the file named "bin/ls" inside the file system on partition number 3. This is the layer at which most applications operate. Following the unix philosophy, the kernel presents an interface to each of these layers, including access controls. For the raw disk layer, there is a block device like /dev/sda. You can read byte number 13543287 of /dev/sda and see what it is. In order to do this, you need read permission on the /dev/sda file. At the partition layer, there are block devices like /dev/sda3. You can read byte number 9986351 of /dev/sda3 and see what it is. For this, you need read permission on the /dev/sda3 file. Those are simplistic layers, and not often used. Pretty much the only time you would ever read from one of those devices is to retrieve the partition table from the disk, or to see what kind of file system is on a given partition. Lower level tools like mkfs and fsck and fdisk and lsblk handle these details. Things become much more interesting when we move up to the file system layer. The first thing to know about file systems is that they have to be "mounted" in order to work. The word "mount" comes from old tape drive technology (reel to reel), when operators would be requested to mount a tape, which is a physical act not dissimilar to hanging a picture on a wall. It has been adopted for file systems, even though there isn't a physical movement of objects. In order to mount a file system, you need to know which disk or partition the file system is stored on, and what directory you want to attach it to. You also have to be root, because this is a potentially VERY intrusive thing to do. If an ordinary user could mount a file system on /bin then he could easily take over the whole system, because users would be executing HIS version of /bin/ls and so on. Typically the directory where you mount a file system is just an empty stub. But it doesn't have to be. Let's say you have a single file system (/) mounted currently, and it has a directory called "home" in it. Now let's say you've got some files in this directory. If you mount /dev/sda3 on /home then the contents of /dev/sda3's file system become visible inside /home. The files that you saw in /home BEFORE the mount are hidden. They're still in the / file system but you can't see them or interact with them. The second thing you need to know about file systems is that they have their own metadata. File ownerships, permissions, and so on are stored within the inodes (index nodes) of the file system. When you mount the file system, you see only the files and the metadata from the mounted file system. The metadata of the directory that you mounted it on is no longer relevant. The metadata of the block device that stores the file system is also irrelevant. Before mounting: drwxr-xr-x 4 john doe 4096 Aug 22 11:41 /home After mounting: drwxr-xr-x 4 root root 4096 Sep 22 11:41 /home Block device: brw-rw---- 1 root disk 8, 3 Nov 1 09:39 /dev/sda3 The group "disk" may have write access to /dev/sda3, but that doesn't let them write to /home. The permissions of /dev/sda3 are not relevant when operating at the file system level. On the other hand, a user in group disk could write arbitrary bytes to the sda3 partition, which would almost certainly CORRUPT the file system, because changes to the underlying partition would be at war with changes made through the file system layer. You never, ever want to write to a device that is also mounted as a file system (unless it's mounted read-only). This is why you don't put ordinary users into the disk group. The third thing you need to know about file systems is that, while you do have to be root to mount them, there are tools that let ordinary users TEMPORARILY have the root privileges needed to mount and unmount file systems. For example, -rwsr-xr-x 1 root root 40000 Mar 29 2015 /bin/mount The mount program is setuid root. It has to be, in order for regular users to be able to use it to mount file systems with temporary root privileges. Now obviously you don't want anyone to be able to mount any file system on any directory. That would be devastating. So there is an access control: the /etc/fstab file system defines what is allowed to be mounted where, by ordinary users. You do this by specifying the "user" option on a file system entry. The /etc/fstab file is only writable by root, so ordinary users can't given themselves the ability to mount stuff wherever they please. As another example, Linux has a subsystem called "FUSE", which allows users to mount some kinds of file systems on directories where they have write permission. sshfs is one example of this. An ordinary user can use the sshfs command to connect to a remote SFTP/SSH server in such a way that the server's files become visible as a mounted file system on the local machine. Reads and writes are translated into SFTP commands. And then there's autofs. I... won't even try to cover autofs here. This email is already long enough. And then there's NFS, and iSCSI... same thing here. Not gonna touch those right now. Of course, these are special exceptions. On most systems, the set of mounted file systems is defined during installation (possibly modified when a new disk is added, or when a new partition is created). These file systems are defined in /etc/fstab, and they're all mounted when the system boots. If you want to share the file system on the /dev/sda13 partition across multiple operating system installations, you simply add an entry in /etc/fstab which says where you want to mount it at boot time, and presto! It will be mounted there. You do this in each operating system's own /etc/fstab file so that each one of them mounts it when it boots.