Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #227135
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: Two questions about LUKS in a file container |
| Date | 2020-09-19 23:10 +0200 |
| Message-ID | <AQShk-7Fp-3@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <APBsf-1U1-11@gated-at.bofh.it> <APLKW-8b3-11@gated-at.bofh.it> <APNjI-KD-7@gated-at.bofh.it> <AQ8Rc-5yZ-27@gated-at.bofh.it> <AQMvg-40f-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Two questions about LUKS in a file container rhkramer@gmail.com - 2020-09-12 18:20 +0200
Re: Two questions about LUKS in a file container Hans <hans.ullrich@loop.de> - 2020-09-12 18:50 +0200
Re: Two questions about LUKS in a file container Bob Weber <bobrweber@gmail.com> - 2020-09-12 21:10 +0200
Re: Two questions about LUKS in a file container Andrei POPESCU <andreimpopescu@gmail.com> - 2020-09-16 11:00 +0200
Re: Two questions about LUKS in a file container David Christensen <dpchrist@holgerdanske.com> - 2020-09-16 22:00 +0200
Re: Two questions about LUKS in a file container David Wright <deblis@lionunicorn.co.uk> - 2020-09-16 23:40 +0200
Re: Two questions about LUKS in a file container David Christensen <dpchrist@holgerdanske.com> - 2020-09-17 22:40 +0200
Re: Two questions about LUKS in a file container David Wright <deblis@lionunicorn.co.uk> - 2020-09-19 17:00 +0200
Re: Two questions about LUKS in a file container David Christensen <dpchrist@holgerdanske.com> - 2020-09-19 23:10 +0200
Re: Two questions about LUKS in a file container Andrei POPESCU <andreimpopescu@gmail.com> - 2020-09-21 08:00 +0200
Re: Two questions about LUKS in a file container David Wright <deblis@lionunicorn.co.uk> - 2020-09-21 16:30 +0200
Re: Two questions about LUKS in a file container Charles Curley <charlescurley@charlescurley.com> - 2020-09-12 21:40 +0200
Re: Two questions about LUKS in a file container David Christensen <dpchrist@holgerdanske.com> - 2020-09-13 01:00 +0200
Re: Two questions about LUKS in a file container David Christensen <dpchrist@holgerdanske.com> - 2020-09-13 00:20 +0200
Re: Two questions about LUKS in a file container rhkramer@gmail.com - 2020-09-13 02:10 +0200
Re: Two questions about LUKS in a file container David Wright <deblis@lionunicorn.co.uk> - 2020-09-13 17:20 +0200
Re: Two questions about LUKS in a file container David <bouncingcats@gmail.com> - 2020-09-13 17:30 +0200
csiph-web