Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #226932 > unrolled thread

Two questions about LUKS in a file container

Back to article view | Back to linux.debian.user

Contents

  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

#226932 — Two questions about LUKS in a file container

I'm thinking about putting my backup encrypted files in a LUKS filesystem within 
a file instead of on a dedicated partition (for a few reasons).

I have two questions about that:

   * if I don't have that LUKS filesystem "mounted" and open and I write to it, 
I assume (or hope) that nothing will get written and I will get a warning or 
error message of some sort?

   * doesn't exactly apply to this situation, but, on the other hand, if my 
"source" / original / non-backup LUKS system is in a file instead of on a 
dedicated partition, and I use commands (like rsync or such) to copy the 
unencrypted files not on the LUKS system, but I use options like the ones to 
stay on the current filesystem (--one-file-system), I assume (or hope) that the 
stuff in the encrypted partition will not get copied?

 

[toc] | [next] | [standalone]

#226933

[Multipart message — attachments visible in raw view] — view raw

Am Samstag, 12. September 2020, 18:10:48 CEST schrieb rhkramer@gmail.com:
Hi, 
> I'm thinking about putting my backup encrypted files in a LUKS filesystem
> within a file instead of on a dedicated partition (for a few reasons).
> 
> I have two questions about that:
> 
>    * if I don't have that LUKS filesystem "mounted" and open and I write to
> it, I assume (or hope) that nothing will get written and I will get a
> warning or error message of some sort?
> 

As far as I know, it is not possible, to mount an encrypted partition at all.


>    * doesn't exactly apply to this situation, but, on the other hand, if my
> "source" / original / non-backup LUKS system is in a file instead of on a
> dedicated partition, and I use commands (like rsync or such) to copy the
> unencrypted files not on the LUKS system, but I use options like the ones to
> stay on the current filesystem (--one-file-system), I assume (or hope) that
> the stuff in the encrypted partition will not get copied?

Hmm, not quite sure, what you asked, but as far as I know, rsync does not 
care, if the files or filesystems are encrypted or not. It just copies the 
stuff to the target byte by byte. If there is something overwritten or not 
readable / writable depends of your normal access rights.

Or am I wrong???

Best regards

Hans

[toc] | [prev] | [next] | [standalone]

#226937

[Multipart message — attachments visible in raw view] — view raw

On 9/12/20 12:10 PM, rhkramer@gmail.com wrote:
> I'm thinking about putting my backup encrypted files in a LUKS filesystem within
> a file instead of on a dedicated partition (for a few reasons).
>
> I have two questions about that:
>
>     * if I don't have that LUKS filesystem "mounted" and open and I write to it,
> I assume (or hope) that nothing will get written and I will get a warning or
> error message of some sort?
>
>     * doesn't exactly apply to this situation, but, on the other hand, if my
> "source" / original / non-backup LUKS system is in a file instead of on a
> dedicated partition, and I use commands (like rsync or such) to copy the
> unencrypted files not on the LUKS system, but I use options like the ones to
> stay on the current filesystem (--one-file-system), I assume (or hope) that the
> stuff in the encrypted partition will not get copied?
>
>   

I assume that you are referring to something like is described here:

https://willhaley.com/blog/encrypted-file-container-disk-image-in-linux/

The procedure described there creates a file encrypted.img that is a luks volume 
that requires a filesystem (mkfs.ext4) and mount point to be used as a encrypted 
storage.  If you want you can leave out --key-file mykey.keyfile and you will be 
asked for a pass phrase.

Files can be copied with rsync to the mount point $HOME/Private/ and they will 
be encrypted and not visible to the system after the umount and cryptsetup 
luksClose commands.

In my experiment the file encrypted.img can be written to or truncated while it 
is being used as a mounted encrypted volume but once you umount and luksClose 
the file ALL DATA is lost!  So to be safe let the file encrypted.img belong to 
root (with mode 600) and let a normal user write to the mounted volume at 
$HOME/Private/ after the chown command is run for the user.  Once the file 
encrypted.img is unmounted and closed out with luksClose it can be copied or 
moved to other places like a flash drive like any other file.

Warning: If you forget to open and mount the file encrypted.img to 
$HOME/Private/ and you copy files to $HOME/Private/ it will appear to work 
correctly but they will not be encrypted!  If you don't move the files out of 
$HOME/Private/ before you correct the mistake and mount encrypted.img you will 
not see those files in $HOME/Private/ until you unmount encrypted.img.

Note:

By saying mount encrypted.img I mean the 2 commands: "cryptsetup luksOpen 
encrypted.img myEncryptedVolume" and then "mount /dev/mapper/myEncryptedVolume 
$HOME/Private/".

The unmount encrypted.img commands are "umount $HOME/Private/" and "cryptsetup 
luksClose myEncryptedVolume".


I am not an expert on cryptsetup.  I have used these commands before but I was 
curious to see if the system it protected encrypted.img while it was being 
used.  I see that root can muck around with or delete encrypted.img making it 
unusable so your only protections are just like other files .... backup!



-- 


*...Bob*

[toc] | [prev] | [next] | [standalone]

#227027

[Multipart message — attachments visible in raw view] — view raw

On Sb, 12 sep 20, 15:00:57, Bob Weber wrote:
> 
> Warning: If you forget to open and mount the file encrypted.img to
> $HOME/Private/ and you copy files to $HOME/Private/ it will appear to work
> correctly but they will not be encrypted!  If you don't move the files out
> of $HOME/Private/ before you correct the mistake and mount encrypted.img you
> will not see those files in $HOME/Private/ until you unmount encrypted.img.

Regardless if encrypted or not, I think it is good practice to have all 
mountpoints (NOT filesystems) owned by root and permission 0000.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#227044

On 2020-09-16 01:59, Andrei POPESCU wrote:
> On Sb, 12 sep 20, 15:00:57, Bob Weber wrote:
>>
>> Warning: If you forget to open and mount the file encrypted.img to
>> $HOME/Private/ and you copy files to $HOME/Private/ it will appear to work
>> correctly but they will not be encrypted!  If you don't move the files out
>> of $HOME/Private/ before you correct the mistake and mount encrypted.img you
>> will not see those files in $HOME/Private/ until you unmount encrypted.img.
> 
> Regardless if encrypted or not, I think it is good practice to have all
> mountpoints (NOT filesystems) owned by root and permission 0000.

That's an interesting suggestion.  /f1 is a mount point on my 
workstation for the root filesystem on one of my servers:

2020-09-16 12:34:14 root@tinkywinky ~
# grep f1 /etc/fstab
f1:/						/f1				fuse.sshfs	ro,noauto			0	0


It is not mounted:

2020-09-16 12:34:20 root@tinkywinky ~
# mount | grep f1


The permissions on the mount point are default, as set by mkdir(1):

2020-09-16 12:35:42 root@tinkywinky ~
# ll -d /f1
drwxr-xr-x 2 root root 4096 2020-09-16 12:33:41 /f1/


If I change the mode of the mount point to 0000:

2020-09-16 12:51:28 root@tinkywinky ~
# chmod 0000 /f1

2020-09-16 12:53:08 root@tinkywinky ~
# ls -la /f1
total 8
d---------  2 root root 4096 Sep 16 12:53 .
drwxr-xr-x 26 root root 4096 Aug 30 13:39 ..


Root can still create files inside the mount point:

2020-09-16 12:53:09 root@tinkywinky ~
# echo 'hello, world!' > /f1/hello

2020-09-16 12:53:41 root@tinkywinky ~
# ls -la /f1
total 12
d---------  2 root root 4096 Sep 16 12:53 .
drwxr-xr-x 26 root root 4096 Aug 30 13:39 ..
-rw-r--r--  1 root root   14 Sep 16 12:53 hello

2020-09-16 12:53:44 root@tinkywinky ~
# cat /f1/hello
hello, world!


Is there some advantage other than making a long listing visually 
distinctive when the mount point is not in use?


David

[toc] | [prev] | [next] | [standalone]

#227046

On Wed 16 Sep 2020 at 12:56:36 (-0700), David Christensen wrote:
> On 2020-09-16 01:59, Andrei POPESCU wrote:
> > On Sb, 12 sep 20, 15:00:57, Bob Weber wrote:
> > > 
> > > Warning: If you forget to open and mount the file encrypted.img to
> > > $HOME/Private/ and you copy files to $HOME/Private/ it will appear to work
> > > correctly but they will not be encrypted!  If you don't move the files out
> > > of $HOME/Private/ before you correct the mistake and mount encrypted.img you
> > > will not see those files in $HOME/Private/ until you unmount encrypted.img.
> > 
> > Regardless if encrypted or not, I think it is good practice to have all
> > mountpoints (NOT filesystems) owned by root and permission 0000.
> 
> That's an interesting suggestion.  /f1 is a mount point on my
> workstation for the root filesystem on one of my servers:
> 
> 2020-09-16 12:34:14 root@tinkywinky ~
> # grep f1 /etc/fstab
> f1:/	/f1	fuse.sshfs	ro,noauto	0	0
> 
> 
> It is not mounted:
> 
> 2020-09-16 12:34:20 root@tinkywinky ~
> # mount | grep f1
> 
> 
> The permissions on the mount point are default, as set by mkdir(1):
> 
> 2020-09-16 12:35:42 root@tinkywinky ~
> # ll -d /f1
> drwxr-xr-x 2 root root 4096 2020-09-16 12:33:41 /f1/
> 
> 
> If I change the mode of the mount point to 0000:
> 
> 2020-09-16 12:51:28 root@tinkywinky ~
> # chmod 0000 /f1
> 
> 2020-09-16 12:53:08 root@tinkywinky ~
> # ls -la /f1
> total 8
> d---------  2 root root 4096 Sep 16 12:53 .
> drwxr-xr-x 26 root root 4096 Aug 30 13:39 ..
> 
> 
> Root can still create files inside the mount point:
> 
> 2020-09-16 12:53:09 root@tinkywinky ~
> # echo 'hello, world!' > /f1/hello
> 
> 2020-09-16 12:53:41 root@tinkywinky ~
> # ls -la /f1
> total 12
> d---------  2 root root 4096 Sep 16 12:53 .
> drwxr-xr-x 26 root root 4096 Aug 30 13:39 ..
> -rw-r--r--  1 root root   14 Sep 16 12:53 hello
> 
> 2020-09-16 12:53:44 root@tinkywinky ~
> # cat /f1/hello
> hello, world!
> 
> 
> 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. You've confirmed
that unix file permissions don't affect root.

Another side-effect is that you can't enter the mountpoint directory
in, say, mc, which avoids your thinking that the intended filesystem
(were it actually mounted) is itself empty.

But—I see that your own intended filesystem for f1 is fuse.sshfs.
Can you, as a user, mount this filesystem now? I'd be interested
to know how, if you can, because I'm just now thinking about enhancing
my udev rule to chown a mount (in favour of me) if the fstab entry
is a fuse one (eg ntfs and exfat).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#227089

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


> Another side-effect is that you can't enter the mountpoint directory
> in, say, mc, which avoids your thinking that the intended filesystem
> (were it actually mounted) is itself empty.

2020-09-17 13:23:59 dpchrist@tinkywinky ~
$ ssh root@localhost
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) x86_64
Last login: Wed Sep 16 12:31:13 2020 from ::1

2020-09-17 13:24:03 root@tinkywinky ~
# chmod 0000 /f1

2020-09-17 13:24:08 root@tinkywinky ~
# q
logout
Connection to localhost closed.

2020-09-17 13:24:17 dpchrist@tinkywinky ~
$ cd /f1
bash: cd: /f1: Permission denied


Confirmed -- changing mode to 0000 prevents non-root users from changing 
into that directory.


> But—I see that your own intended filesystem for f1 is fuse.sshfs.
> Can you, as a user, mount this filesystem now? I'd be interested
> to know how, if you can, because I'm just now thinking about enhancing
> my udev rule to chown a mount (in favour of me) if the fstab entry
> is a fuse one (eg ntfs and exfat).

I have always mounted /f1 as root.  Trying it as non-root:

2020-09-17 13:24:24 dpchrist@tinkywinky ~
$ mount /f1
mount: only root can mount f1:/ on /f1


David

[toc] | [prev] | [next] | [standalone]

#227132

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.

> > Another side-effect is that you can't enter the mountpoint directory
> > in, say, mc, which avoids your thinking that the intended filesystem
> > (were it actually mounted) is itself empty.
> 
> 2020-09-17 13:23:59 dpchrist@tinkywinky ~
> $ ssh root@localhost
> Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) x86_64
> Last login: Wed Sep 16 12:31:13 2020 from ::1
> 
> 2020-09-17 13:24:03 root@tinkywinky ~
> # chmod 0000 /f1
> 
> 2020-09-17 13:24:08 root@tinkywinky ~
> # q
> logout
> Connection to localhost closed.
> 
> 2020-09-17 13:24:17 dpchrist@tinkywinky ~
> $ cd /f1
> bash: cd: /f1: Permission denied
> 
> Confirmed -- changing mode to 0000 prevents non-root users from
> changing into that directory.
> 
> > But—I see that your own intended filesystem for f1 is fuse.sshfs.
> > Can you, as a user, mount this filesystem now? I'd be interested
> > to know how, if you can, because I'm just now thinking about enhancing
> > my udev rule to chown a mount (in favour of me) if the fstab entry
> > is a fuse one (eg ntfs and exfat).
> 
> I have always mounted /f1 as root.  Trying it as non-root:
> 
> 2020-09-17 13:24:24 dpchrist@tinkywinky ~
> $ mount /f1
> mount: only root can mount f1:/ on /f1

Oh, OK. 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.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#227135

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

[toc] | [prev] | [next] | [standalone]

#227198

[Multipart message — attachments visible in raw view] — view raw

On Sb, 19 sep 20, 09:57:37, David Wright wrote:
> 
> 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).

https://fossbytes.com/linux-5-7-microsofts-exfat-driver-code/

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#227209

On Sat 19 Sep 2020 at 14:09:07 (-0700), David Christensen wrote:
> On 2020-09-19 07:57, David Wright wrote:
> > 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?

I think exfat-fuse is what I am using, and fusefat appears to consider
rw as experimental, from what I have read.

On Mon 21 Sep 2020 at 08:53:00 (+0300), Andrei POPESCU wrote:
> On Sb, 19 sep 20, 09:57:37, David Wright wrote:
> > 
> > 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).
> 
> https://fossbytes.com/linux-5-7-microsofts-exfat-driver-code/

Thanks. In which case, I think I'll pause on doing anything about
exFAT in the immediate future. Currently I max out at 32GB on SD
cards; anything larger is either USB or spinning rust. (Also, as
I write this, my SO is getting ubuntu installed as a VM on her
Windows machine.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#226939

On Sat, 12 Sep 2020 12:10:48 -0400
rhkramer@gmail.com wrote:

> I'm thinking about putting my backup encrypted files in a LUKS
> filesystem within a file instead of on a dedicated partition (for a
> few reasons).

Why do you want a file system inside a file? The only reason I can
think of to do that is to emulate the file system of another computer,
e.g. a virtual machine. But in that case, I wonder why you want to feed
your backups to a VM.

> 
> I have two questions about that:
> 
>    * if I don't have that LUKS filesystem "mounted" and open and I
> write to it, I assume (or hope) that nothing will get written and I
> will get a warning or error message of some sort?

It depends.

If you are create a new file to write to, and it would be in the root
director of the partition (e.g. /mnt/foo), then Linux will cheerfully
create the file and write to it in the mount point directory, on that
file system.

If you try to open an existing file, it will fail.

Otherwise, you will get an error because the directory structure won't
be there.

Whether you get an error message or not depends on which program you
use.

> 
>    * doesn't exactly apply to this situation, but, on the other hand,
> if my "source" / original / non-backup LUKS system is in a file
> instead of on a dedicated partition, and I use commands (like rsync
> or such) to copy the unencrypted files not on the LUKS system, but I
> use options like the ones to stay on the current filesystem
> (--one-file-system), I assume (or hope) that the stuff in the
> encrypted partition will not get copied?

Huh?

Figure out which program you are going to use, and read the man page.



You appear to specialize in coming up with oddball solutions to
problems and then asking us how to implement your solution.

Instead, how about describing your problem and asking how we would
suggest you solve it? Plenty of us have already dealt with the sorts of
problems you seem to have, and solved them.

As far as getting backups onto encrypted partitions, say for off-site
storage, goes: I have a solution that works for me. Start with
http://charlescurley.com/blog/posts/2019/Nov/02/backups-on-linux/


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#226949

On 2020-09-12 12:14, Charles Curley wrote:
> On Sat, 12 Sep 2020 12:10:48 -0400
> rhkramer@gmail.com wrote:
> 
>> I'm thinking about putting my backup encrypted files in a LUKS
>> filesystem within a file instead of on a dedicated partition (for a
>> few reasons).
> 
> Why do you want a file system inside a file? The only reason I can
> think of to do that is to emulate the file system of another computer,
> e.g. a virtual machine.

There are many use-cases.  In the context of rsync(1) backups, each file 
contains one backup filesystem.  If you have seven such files, you can 
rotate them daily and one complete backup for each day of the week.  If 
you set the backup image file permissions correctly, you can easily view 
and/or move those files using standard tools.  But, one challenge is 
finding the "right" file size.  Some people use LVM inside the files to 
provide additional flexibility.


David

[toc] | [prev] | [next] | [standalone]

#226948

On 2020-09-12 09:10, rhkramer@gmail.com wrote:
> I'm thinking about putting my backup encrypted files in a LUKS filesystem within
> a file instead of on a dedicated partition (for a few reasons).
> 
> I have two questions about that:
> 
>     * if I don't have that LUKS filesystem "mounted" and open and I write to it,
> I assume (or hope) that nothing will get written and I will get a warning or
> error message of some sort?

AIUI "LUKS volumes" are "opened" and "closed", and "filesystems" are 
"mounted" and "unmounted".


If you issue a command that writes into a file containing a LUKS volume, 
open or closed, you will corrupt things:

https://lists.debian.org/debian-user/2020/08/msg00690.html


>     * doesn't exactly apply to this situation, but, on the other hand, if my
> "source" / original / non-backup LUKS system is in a file instead of on a
> dedicated partition, and I use commands (like rsync or such) to copy the
> unencrypted files not on the LUKS system, but I use options like the ones to
> stay on the current filesystem (--one-file-system), I assume (or hope) that the
> stuff in the encrypted partition will not get copied?

When using the rsync(1) with the "--recursive" option, adding the 
"--one-file-system" option prevents rsync(1) from recursing into mount 
points under SRC.


For example, my workstations include the directory 
"/home/dpchrist/samba/dpchrist".  It is the mount point for a share on 
the server "samba".  The server data is backed up by one job. 
Workstation home directories are backed up by another job.  The home 
directory backup jobs use the "--one-file-system" option, so that the 
server data is not backed up multiple times.


I would avoid issuing one rsync(1) command that includes both a LUKS/ 
filesystem image file and its mount point as SRC arguments or under SRC 
arguments.  It might "work", but the results could be surprising.


David

[toc] | [prev] | [next] | [standalone]

#226952

Thank you!

(Nothing new below this line.)

On Saturday, September 12, 2020 06:14:33 PM David Christensen wrote:
> On 2020-09-12 09:10, rhkramer@gmail.com wrote:
> > I'm thinking about putting my backup encrypted files in a LUKS filesystem
> > within a file instead of on a dedicated partition (for a few reasons).

[toc] | [prev] | [next] | [standalone]

#226963

On Sat 12 Sep 2020 at 12:10:48 (-0400), rhkramer@gmail.com wrote:
> I'm thinking about putting my backup encrypted files in a LUKS filesystem within 
> a file instead of on a dedicated partition (for a few reasons).
> 
> I have two questions about that:
> 
>    * if I don't have that LUKS filesystem "mounted" and open and I write to it, 
> I assume (or hope) that nothing will get written and I will get a warning or 
> error message of some sort?

Create a permanent mount point with the permissions set to ugo=
ie nothing.

If you're afraid that root will read or write to it,
then instead use a script like the following:

. unlock the LUKS
. mkdir the mount point
. mount the filesystem

When finished with the container, another script:

. umount the filesystem
. rmdir the mount point
. lock the LUKS

To have the mount point cleaned up when you close down (forgetting to run
the latter script), make the mount point under /tmp.

>    * doesn't exactly apply to this situation, but, on the other hand, if my 
> "source" / original / non-backup LUKS system is in a file instead of on a 
> dedicated partition, and I use commands (like rsync or such) to copy the 
> unencrypted files not on the LUKS system, but I use options like the ones to 
> stay on the current filesystem (--one-file-system), I assume (or hope) that the 
> stuff in the encrypted partition will not get copied?

I assume that --one-file-system would notice that the encrypted
filesystem is read from /dev/dm-*, whereas the container file is
being read from /dev/sd*, and would avoid using the former.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#226964

On Mon, 14 Sep 2020 at 01:10, David Wright <deblis@lionunicorn.co.uk> wrote:

> Create a permanent mount point with the permissions set to ugo=
> ie nothing.

I do this for all my permanent mountpoints and then set the
immutable bit on them.

This prevents accidental writes and the bonus is that
  ls -l /mnt
shows clearly which of its subdirectories are in use as
mountpoints, (assuming that what is mounted has
typical nonzero permissions). Handy when there's a lot
of them.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web