Re: Problem attempting to use xorriso
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.
Reply to: