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