Thanks, Greg! That's brilliant! \o/ Lisi
On Thursday 10 November 2016 15:41:02 Greg Wooledge wrote: > 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.