[sf-lug] mounting and permissions

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] mounting and permissions
> Date: Fri, 15 Apr 2022 01:02:19 -0700

> Quoting Alex Kleider (alexkleider at protonmail.com):
>
>> I'm running Debian 10/xfce
>> Only root is authorized to mount.
>> When I mount a thumb drive, the owner of the mount point is root:root

That will also typically be the default behavior for many types of
non-POSIX (e.g. various flavors of FAT) filesystems - as
there may not be or may not be any type of direct equivalence to
POSIX ownerships, permissions, etc.
E.g. NTFS has no "execute" permissions.  FAT has no ownerships.  Etc.
So, Linux (and more generally *nix) conveniently does some type of
(approximate) mapping so one can actually mount and use it on Linux
as if it were, at least approximately, a POSIX filesystem.  However,
many types of operations (e.g. chown, chmod, etc.) won't quite work as
one might otherwise expect ... notably as the filesystem itself may
entirely lack corresponding attributes ... so there may be no change
or the change may only be some approximation of what may have been
requested.

As for, e.g. FAT flavors of filesystems, one can pass various mount
options, e.g. uid= and gid=, to have the filesystem mounted having that
respectively UID and GID ownership ... for everything on the filesystem.
Likewise FAT lacks most permissions of POSIX,
so, POSIX has write, FAT has read-only (ro), but POSIX has write for
ugo, whereas FAT only has ro that applies to all (there are no users
or groups on FAT).
So, the mount option for FAT type filesystems also includes option(s)
to set the permissions - which will set the permissions for the entire
mounted filesystem (and may be logically combined with what limited
permissions FAT offers, e.g. mounting read-write (rw) may still
leave FAT files that are ro set as lacking write for ugo on Linux).

Another bit that may be quite useful for, e.g. USB,
rather than giving the current /dev/sd* where the device/partition
happens to be, use a persistent name under /dev.  That way if/when
you go to mount it, if you connected it in a different order, or used
a different USB port, device can still be found via same name and
mounted with same name.
E.g.:
/dev/disk/by-id/usb-SanDisk_Cruzer_Blade_4C532000030915103390-0:0
That's for a USB flash stick I have ... I can connect it anywhere
on the host and it will be accessible using that name.
And, how do you find such names?  Well, can search 'em out.
E.g., let's say I plug that in ...
and it shows up as /dev/sdc
Well ...
# ls -ond /dev/sdc
brw-rw---- 1 0 8, 32 Apr 17 06:45 /dev/sdc
# find /dev -xdev -follow -type b -exec ls -Lond \{\} \; | grep ' 8, *32 '
brw-rw---- 1 0 8, 32 Apr 17 06:45 /dev/sdc
brw-rw---- 1 0 8, 32 Apr 17 06:45  
/dev/disk/by-id/usb-SanDisk_Cruzer_Blade_4C532000030915103390-0:0
brw-rw---- 1 0 8, 32 Apr 17 06:45  
/dev/disk/by-path/pci-0000:00:1d.0-usb-0:1.1:1.0-scsi-0:0:0:0
brw-rw---- 1 0 8, 32 Apr 17 06:45 /dev/block/8:32
#
It's block device, major # 8, minor # 32 ... but there are multiple
pathnames under /dev that refer to that - so different names/paths
for the same device.
That
/dev/disk/by-id/usb-SanDisk_Cruzer_Blade_4C532000030915103390-0:0
one will be the same regardles of where it gets connected,
whereas the others will depend upon where it's connected and/or the
sequence in which it's connected.  Anyway, similar can also typically
be done for partitions too, if/as applicable.  E.g. with that
same USB flash:
# ls -ond /dev/sdc1
brw-rw---- 1 0 8, 33 Apr 17 06:45 /dev/sdc1
# find /dev -xdev -follow -type b -exec ls -Lond \{\} \; | grep ' 8, *33 '
brw-rw---- 1 0 8, 33 Apr 17 06:45 /dev/sdc1
brw-rw---- 1 0 8, 33 Apr 17 06:45  
/dev/disk/by-uuid/6ca0a624-17b2-447c-a06e-b7be2b691c1e
brw-rw---- 1 0 8, 33 Apr 17 06:45 /dev/disk/by-partuuid/00095e01-01
brw-rw---- 1 0 8, 33 Apr 17 06:45  
/dev/disk/by-id/usb-SanDisk_Cruzer_Blade_4C532000030915103390-0:0-part1
brw-rw---- 1 0 8, 33 Apr 17 06:45  
/dev/disk/by-path/pci-0000:00:1d.0-usb-0:1.1:1.0-scsi-0:0:0:0-part1
brw-rw---- 1 0 8, 33 Apr 17 06:45 /dev/block/8:33
#
For a persistent name for partition 1, we could use:
/dev/disk/by-id/usb-SanDisk_Cruzer_Blade_4C532000030915103390-0:0-part1

Anyway, with suitable /etc/fstab entry, mount could be as simple
and consistent as:
# mount /whatever/mount_point/directory/I/gave/it

>> but even root doesn't have authority to  # chown alex:alex ~alex/mnt

Yes, because one can't change what doesn't exist.
Trying to paint a red wall blue doesn't work very well if there's
no wall.

>> Surely there must be a way that I can mount something and have  
>> permission to write to it?
>> Can anyone enlighten me?

> Here's one way:
>
> Quoting from the "man 8 mount" section for FAT filesystems:
>
>        uid=value and gid=value
>               Set the owner and group of all files.  (Default: the  
> uid and gid
>               of the current process.)
>
> Of course, you'd prolly wanna automate that, so here's the relevant
> excerpt from "man 5 fstab" about the format of /etc/fstab (the
> filesystem table, parsed and fed to /bin/mount at boot time):
>
>       The fourth field, (fs_mntops), describes the mount  options associated
>        with the filesystem.

One can also give option(s),
noauto - so it won't try to automatically
mount it at boot (or with mount -a), one can use that and/or
nofail - so if the mount attempt fails that's not regarded as
a "failure" as far as /etc/fstab processing via mount -a or the like
is concerned (it won't exit/return non-zero on account of that mount
attempt failure, though it will still generally write the diagnostics)
... so, e.g. at boot it won't force you into maintenance
mode or the like asking you to manually fix the "broken" filesystem
(like if you didn't have that USB inserted when you were booting).

>        It  is  formatted as a comma separated list of options.  It  
> contains at
>        least the type of mount plus any additional options  
> appropriate to  the
>        filesystem  type.   For documentation on the available  
> options for non-
>        nfs file systems, see mount(8).  For documentation on all nfs-specific
>        options have a look at nfs(5).  Common for all types of file  
> system are
>        the options ``noauto'' (do not mount when "mount -a" is  
> given, e.g., at
>        boot  time),  ``user''  (allow  a  user to mount), and  
> ``owner'' (allow
>        device owner to mount), and ``comment'' (e.g., for use  by fstab-main-
>        taining  programs).   The  ``owner'' and ``comment'' options  
> are Linux-
>        specific.  For more details, see mount(8).
>
>
> Example fstab line:
>
> /dev/sdc1      /mnt/shared     vfat uid=myuseruid,gid=myusergid 0 0
>
> (where myuseruid and myusergid are numbers)
>
> 'Hope that helps.
>
>
> Bonus tip:  In that or any/all other mountpoint directories,
> go there with root access (with nothing mounted at the mountpoint) and
> do:
>
>     touch NOTHING_IS_MOUNTED_HERE
>
> This creates a zero-length, root-owned file of that name.  Point is,
> it's a visual indicator.  Any files within a mountpoint are
> automatically rendered invisible while something is mounted at the
> mountpoint, and return to visibility the moment the filesystem gets
> umounted.

Or, what I prefer to do, is use df with some pathname argument(s),
which may be a mount point, or any pathnames(s) to whatever on
whatever filesystem(s) ... though it may be simplest and most
clear with, e.g. a single argument.  And, df will
happily report upon the filesystem whereupon that path exists.
E.g.:
$ df /var/local/ISOs/newer/debian-11.0.0-amd64-netinst.iso
Filesystem              1K-blocks      Used Available Use% Mounted on
/dev/mapper/tigger-ISOs 354946012 354315352    630660 100% /var/local/ISOs
$
So ... I can see that pathname is on my /var/local/ISOs filesystem,
and not, e.g. my /var or / filesystem.  I could seen that
just as well if I'd given argument of /var/local/ISOs instead.
And it works regardless if somebody did or didn't remember to put some
marker file or directory, e.g. in some otherwise empty moutpoint
directory or filesystem root directory, etc. ... even works across
thousands or more hosts maintained by multiple people.

As someone once wrote (did their thesis on it):
"Comments lie" ... well ... they don't necessarily tell
the truth, anyway.
So ... I prefer to actually check,
rather than assuming that what's implied by, e.g.
the name of a file/directory, or what's in some prompt string, or on some
window title, etc. is actually correct in what it implies ... as it
may not be.  This also becomes particular important in the context of
production systems/environments.  Even if you document and
tell folks to always follow some convention ... doesn't mean
they will in fact always do so ... so generally a good idea
to check/verify - at least as reasonably feasible.

> Do that, and you'll thank yourself, the day you're too tired to notice
> that the reason a tree is suddenly mysteriously empty is that what's
> supposed to be mounted there, isn't.