Re: Two questions about LUKS in a file container
On 2020-09-19 07:57, David Wright wrote:
On Thu 17 Sep 2020 at 13:32:16 (-0700), David Christensen wrote:
On 2020-09-16 14:38, David Wright wrote:
On Wed 16 Sep 2020 at 12:56:36 (-0700), David Christensen wrote:
On 2020-09-16 01:59, Andrei POPESCU wrote:
If I change the mode of the mount point to 0000:
Is there some advantage other than making a long listing visually
distinctive when the mount point is not in use?
Yes. As explained earlier in the thread, it prevents user OP from
accidentally scribbling in the unused mountpoint.
The default permissions 0755 already do that:
2020-09-17 13:21:22 dpchrist@tinkywinky ~
$ touch /f1/foo
touch: cannot touch '/f1/foo': Permission denied
Only because root created the mount point, as root would have to do
for a mount point in /.
The blog example uses $HOME/Private/ which would, with a typical
user's umask, be writeable by the user.
2020-09-19 13:20:00 dpchrist@tinkywinky ~
$ cat /etc/debian_version ; uname -a
9.13
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05)
x86_64 GNU/Linux
2020-09-19 13:24:20 dpchrist@tinkywinky ~
$ mkdir mountpoint
2020-09-19 13:24:24 dpchrist@tinkywinky ~
$ touch mountpoint/foo
2020-09-19 13:24:28 dpchrist@tinkywinky ~
$ chmod 0000 mountpoint
2020-09-19 13:24:37 dpchrist@tinkywinky ~
$ touch mountpoint/bar
touch: cannot touch 'mountpoint/bar': Permission denied
Okay. I can see how that might alert me if I attempt to write to a
mountpoint that is not active.
... I was hoping you might have cracked how to mount a fuse
filesystem as a user, as described in:
What is FUSE?
~~~~~~~~~~~~~
FUSE is a userspace filesystem framework. […]
One of the most important features of FUSE is allowing secure,
non-privileged mounts. This opens up new possibilities for the use of
filesystems. A good example is sshfs: a secure network filesystem
using the sftp protocol.
https://www.kernel.org/doc/Documentation/filesystems/fuse.txt
But with my experiments (on exFAT), I couldn't get past what looks
like #916987:
$ mount /media/cruzer4g/
FUSE exfat 1.3.0
fusermount: unknown option 'user=david'
$
That was after adding user_allow_other to /etc/fuse.conf (which
I didn't want) to get past:
$ mount /media/cruzer4g/
FUSE exfat 1.3.0
fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf
$
… and after being taking ownership of both mount point and device file.
So I'm mounting with sudo, and appending ,umask=077,uid=1000,gid=1000
to the fstab entry to gain user access to the filesystem.
Do you know if fuse exFAT is a stopgap, and support in the kernel is
eventually coming, or was a fuse implementation necessarily chosen
to support exFAT on account of some particular problem. It seems odd
that pmount, for example, doesn't support exFAT (which would seem
a prime candidate).
The fuse documentation is so fragmentary, scattered and sparse that
I haven't really got a good feel for what is is or how it works.
I'm always thinking that I've missed some option or other that allows
it to work as I expected it to.
2020-09-19 14:04:40 dpchrist@tinkywinky ~
$ apt-cache search fuse | grep FAT
exfat-fuse - read and write exFAT driver for FUSE
fusefat - File System in User Space - Module for FAT
umview-mod-umfusefat - View-OS in user space - FAT module for UMFUSE
Have you tried exfat-fuse or fusefat?
David
Reply to: