I have a cryptmounted partition on my system. When mounted it has a
couple of weird directory entries
d????????? ? ? ? ? ? appimagelauncherfs

d????????? ? ? ? ? ? gvfs

What are these all about. They sometimes get left behind when the
partition is unmounted and are unerraseable, even by root
Similarly lsattr on that directory also gives "Permission denied" when
it is run by root.

What are these directories and why is the directory entry so screwed up?



--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 01 May 2021 03:26:35 -0400, William Unruh <unruh@invalid.ca> wrote:

I have a cryptmounted partition on my system. When mounted it has a
couple of weird directory entries
d????????? ? ? ? ? ? appimagelauncherfs

d????????? ? ? ? ? ? gvfs

What are these all about. They sometimes get left behind when the
partition is unmounted and are unerraseable, even by root
Similarly lsattr on that directory also gives "Permission denied" when
it is run by root.

What are these directories and why is the directory entry so screwed up?

Those directories used as mountpoints for file systems the root user does not have read access to.

$ grep id=$UID /proc/mounts
tmpfs /run/user/500 tmpfs rw,nosuid,nodev,relatime,size=1640724k,mode=700,uid=500,gid=500,inode64 0 0
gvfsd-fuse /run/user/500/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=500,group_id=500 0 0
/dev/fuse /run/user/500/doc fuse rw,nosuid,nodev,relatime,user_id=500,group_id=500 0 0

See "man gvfs" for more info.

Similarly the appimagelauncherfs is used with appimages.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2021-05-01, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

On Sat, 01 May 2021 03:26:35 -0400, William Unruh <unruh@invalid.ca> wrote:

I have a cryptmounted partition on my system. When mounted it has a
couple of weird directory entries
d????????? ? ? ? ? ? appimagelauncherfs

d????????? ? ? ? ? ? gvfs

What are these all about. They sometimes get left behind when the
partition is unmounted and are unerraseable, even by root
Similarly lsattr on that directory also gives "Permission denied" when
it is run by root.

What are these directories and why is the directory entry so screwed up?

Those directories used as mountpoints for file systems the root user does not have read access to.

What? root is supposed to have access to anything. How can there be
filesystems that root does not have read access to it? How can you have directory entries that root does not have access to? A directory is
simply a file in linux.

$ grep id=$UID /proc/mounts
tmpfs /run/user/500 tmpfs rw,nosuid,nodev,relatime,size=1640724k,mode=700,uid=500,gid=500,inode64 0 0
gvfsd-fuse /run/user/500/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=500,group_id=500 0 0
/dev/fuse /run/user/500/doc fuse rw,nosuid,nodev,relatime,user_id=500,group_id=500 0 0

See "man gvfs" for more info.

I find that man page particularly impenetrable.

Similarly the appimagelauncherfs is used with appimages.

Regards, Dave Hodgins

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 01 May 2021 12:38:17 -0400, William Unruh <unruh@invalid.ca> wrote:

On 2021-05-01, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

Those directories used as mountpoints for file systems the root user does not
have read access to.

What? root is supposed to have access to anything. How can there be filesystems that root does not have read access to it? How can you have directory entries that root does not have access to? A directory is
simply a file in linux.

Root can access any thing on the local disk file systems, though it may require altering permissions first.

On remote or fuse mounted file systems (mounted by the user, not by root), root can only access them if permission has been granted when they are mounted.

$ grep id=$UID /proc/mounts
tmpfs /run/user/500 tmpfs rw,nosuid,nodev,relatime,size=1640724k,mode=700,uid=500,gid=500,inode64 0 0
gvfsd-fuse /run/user/500/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=500,group_id=500 0 0
/dev/fuse /run/user/500/doc fuse rw,nosuid,nodev,relatime,user_id=500,group_id=500 0 0

See "man gvfs" for more info.

I find that man page particularly impenetrable.

It allows the user to access files on devices or remote file systems. Plug in your
iphone, when it's file systems get mounted, the current desktop user gets access.

In my case I use sshfs to access my files on my oldest computer ...
$ grep ssh /proc/mounts
dave@mine:/ /old fuse.sshfs rw,nosuid,nodev,relatime,user_id=500,group_id=500,allow_other 0 0

I mount it with the command "sshfs dave@mine:/ /old -o allow_other". I have
ssh already setup to allow login using my id and the machine alias "mine", for the
old system.

The allow_other mount parameter allows root to read the files. See man mount.fuse
for more details.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 01.05.2021 at 16:38, William Unruh scribbled:

root is supposed to have access to anything.

Write access, yes. Not necessarily read access. So you'd need to
enable read access for root on the parent directory.

--
With respect,
= Aragorn =


--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Strider (2:250/1@fidonet)

On Sat, 01 May 2021 16:20:55 -0400, Aragorn <thorongil@telenet.be> wrote:

On 01.05.2021 at 16:38, William Unruh scribbled:

root is supposed to have access to anything.

Write access, yes. Not necessarily read access. So you'd need to
enable read access for root on the parent directory.

That won't work for mounted fuse file systems such as sshfs or gvfs unless
the allow_other option was included when it was mounted. Root can not read or write to those mount points without it, no matter what the local file system permissions are for the directory used as the mount point.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2021-05-01, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

On Sat, 01 May 2021 16:20:55 -0400, Aragorn <thorongil@telenet.be> wrote:

On 01.05.2021 at 16:38, William Unruh scribbled:

root is supposed to have access to anything.

Write access, yes. Not necessarily read access. So you'd need to
enable read access for root on the parent directory.

That won't work for mounted fuse file systems such as sshfs or gvfs unless the allow_other option was included when it was mounted. Root can not read or write to those mount points without it, no matter what the local file system permissions are for the directory used as the mount point.

In my case it was a filesystem mounted using cryptmount--ie an encrypted
file used as a partition. I suppose it would be sensible that an
encrypted partition not be readable by root, but it is a local
filesystem, not some remote thing.
Somehow the system also became totally confused, and I was unable to
mount the encrypted file system, mount claiming the mountpoint was in use (It was not in any way I could see).
I finally rebooted and then things went back to normal. A bit tense in
the meantime as all my students marks, essays, final exams were on that encrypted partition.

Regards, Dave Hodgins

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 01 May 2021 19:23:04 -0400, William Unruh <unruh@invalid.ca> wrote:

In my case it was a filesystem mounted using cryptmount--ie an encrypted
file used as a partition. I suppose it would be sensible that an
encrypted partition not be readable by root, but it is a local
filesystem, not some remote thing.
Somehow the system also became totally confused, and I was unable to
mount the encrypted file system, mount claiming the mountpoint was in use (It was not in any way I could see).
I finally rebooted and then things went back to normal. A bit tense in
the meantime as all my students marks, essays, final exams were on that encrypted partition.

Make sure you have a backup, preferably an encrypted one, just in case the drive
it's stored on fails.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2021-05-01, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

On Sat, 01 May 2021 19:23:04 -0400, William Unruh <unruh@invalid.ca> wrote:

In my case it was a filesystem mounted using cryptmount--ie an encrypted
file used as a partition. I suppose it would be sensible that an
encrypted partition not be readable by root, but it is a local
filesystem, not some remote thing.
Somehow the system also became totally confused, and I was unable to
mount the encrypted file system, mount claiming the mountpoint was in use (It was not in any way I could see).
I finally rebooted and then things went back to normal. A bit tense in
the meantime as all my students marks, essays, final exams were on that
encrypted partition.

Make sure you have a backup, preferably an encrypted one, just in case the drive
it's stored on fails.

The problem with backing up an encrypted partition is that the slightest
change means that the whole file has to be backed up again. Ie, no
incrimental backups.

Regards, Dave Hodgins

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 01 May 2021 23:14:23 -0400, William Unruh <unruh@invalid.ca> wrote:

The problem with backing up an encrypted partition is that the slightest change means that the whole file has to be backed up again. Ie, no incrimental backups.

Have the encrypted partition open, create an encrypted partition on the backup device (preferably a removable drive such as a large usb stick) , and use rsync to copy just the changed files.

Best is to setup a script to open the encrypted backup, sync to it, and then close the encrypted backup so it can be kept in a safe place when not in use.

You can set up the encrypted partitions such that when opening, the pass phrase is read from a file on a usb stick that's only present when you want to open the encrypted file system. There's a lot of ways to do it with basic scripting.

I've bought a couple of usb sticks that are 114GiB (marketed as 128 GB) that I use.
https://www.amazon.ca/dp/B015CH1PJU/ref=pe_3034960_236394800_TE_dp_1
That's more than enough for what I absolutely must have backed up. They have 256 GB
drives too, if you need more space for the backup.

Putting the passphrase on a small usb stick instead of typing it in allows you to use something like "mkpasswd -l 128" to create the passphrase. Make sure you have a backup of the usb stick with the passphrase in that case though.

Also put a copy of any scripts or config files you setup in a small, unencrypted
partition on the usb sticks to make recovery easier.

I'm not currently using encryption, but have in the past.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

Aragorn wrote on 2/5/21 6:20 am:

On 01.05.2021 at 16:38, William Unruh scribbled:

root is supposed to have access to anything.

Write access, yes. Not necessarily read access. So you'd need to
enable read access for root on the parent directory.

Sorry, Aragorn, but are you suggesting that if root didn't have access
enabled on the parent directory, it could Write a file called, for
example, 'TesteR' to the parent directory even though there was already
a file called 'TesteR' in that parent directory??
--
Daniel

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 15.05.2021 at 19:52, Daniel65 scribbled:

Aragorn wrote on 2/5/21 6:20 am:

On 01.05.2021 at 16:38, William Unruh scribbled:
=20

root is supposed to have access to anything. =20

=20
Write access, yes. Not necessarily read access. So you'd need to
enable read access for root on the parent directory.
=20

Sorry, Aragorn, but are you suggesting that if root didn't have
access enabled on the parent directory, it could Write a file called,
for example, 'TesteR' to the parent directory even though there was
already a file called 'TesteR' in that parent directory??

Yes. The root account always as write access on everything, but not necessarily read access =E2=80=94 this depends on the permissions.

There is of course a way to limit the root user's write access, i.e. by
using an ACL, but root being root, they can of course modify that ACL
again. =20

Likewise, a read-only filesystem is read-only even to the root account,
but in the same vein, root does have the power to remount the filesystem
as read/write =E2=80=94 at least, provided that the filesystem wasn't (re-)mounted read-only by the kernel because of filesystem damage.

--=20
With respect,
=3D Aragorn =3D


--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Strider (2:250/1@fidonet)

Aragorn wrote on 15/5/21 8:43 pm:

On 15.05.2021 at 19:52, Daniel65 scribbled:

Aragorn wrote on 2/5/21 6:20 am:

On 01.05.2021 at 16:38, William Unruh scribbled:

root is supposed to have access to anything.

Write access, yes. Not necessarily read access. So you'd need to
enable read access for root on the parent directory.

Sorry, Aragorn, but are you suggesting that if root didn't have
access enabled on the parent directory, it could Write a file called,
for example, 'TesteR' to the parent directory even though there was
already a file called 'TesteR' in that parent directory??

Yes. The root account always as write access on everything, but not necessarily read access — this depends on the permissions.

WOW!! What dummie allowed that to apply!! ;-P

There is of course a way to limit the root user's write access, i.e. by
using an ACL, but root being root, they can of course modify that ACL
again.

Likewise, a read-only filesystem is read-only even to the root account,
but in the same vein, root does have the power to remount the filesystem
as read/write — at least, provided that the filesystem wasn't
(re-)mounted read-only by the kernel because of filesystem damage.

--
Daniel

--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 16.05.2021 at 18:45, Daniel65 scribbled:

Aragorn wrote on 15/5/21 8:43 pm:

On 15.05.2021 at 19:52, Daniel65 scribbled:
=20

Aragorn wrote on 2/5/21 6:20 am: =20

On 01.05.2021 at 16:38, William Unruh scribbled:
=20

root is supposed to have access to anything. =20

Write access, yes. Not necessarily read access. So you'd need to
enable read access for root on the parent directory.
=20

Sorry, Aragorn, but are you suggesting that if root didn't have
access enabled on the parent directory, it could Write a file
called, for example, 'TesteR' to the parent directory even though
there was already a file called 'TesteR' in that parent
directory?? =20

=20
Yes. The root account always as write access on everything, but not necessarily read access =E2=80=94 this depends on the permissions. =20

=20
WOW!! What dummie allowed that to apply!! ;-P

Tsk! Those who do not understand UNIX are doomed to reinvent it,
poorly. :p

The root account MUST =E2=80=94 ultimately; see my comment about ACLs =E2= =80=94 have
write access to everything. How else would root be able to fix things
when they break?

But then again, root doesn't always need READ access, so when it comes
to reading a file and/or executing a file, the root account abides by
the regular permissions and ownership. =20

After all, the root account isn't only used by a biological specimen
located in a chair, but also by root-owned processes, and you don't
want those processes to randomly start executing files that aren't
meant to be executed, or files that shouldn't be world-readable.

Learned something you have today, Padawan? :p

--=20
With respect,
=3D Aragorn =3D


--- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
* Origin: A noiseless patient Strider (2:250/1@fidonet)