[pkg-go] Bug#984716: gocryptfs: data loos upon full root file system

[Matthias Jäger]

Package: gocryptfs
Version: 1.6.1-1+b20
Severity: critical
Justification: causes serious data loss

Dear Maintainer,

I'm using a gocryptfs container. Both the save location and mount point are on partitions other then "/" that where not full. Whilst installing packages with apt the root file system got overfilled. After fixing that situation by deleting log files and rebooting (reboot was necessary as for unknown reasons the root file system still reported to be full) I noticed that the content of some of the directories in the mounted gocryptfs were empty.

Running gocryptfs -fsck (...) gave:
Using config file at custom location (...)
Password:
Decrypting master key
OpenDir "": invalid entry "._sync_7629b36e80e0.db-wal": illegal base64 data at input byte 0
OpenDir "": invalid entry "._sync_7629b36e80e0.db-shm": illegal base64 data at input byte 0
fsck: corrupt entry in dir "": "._sync_7629b36e80e0.db-wal"
fsck: corrupt entry in dir "": "._sync_7629b36e80e0.db-shm"
OpenDir "": invalid entry "._sync_7629b36e80e0.db": illegal base64 data at input byte 0
fsck: corrupt entry in dir "": "._sync_7629b36e80e0.db"
fsck: error opening dir "(...)": 2=no such file or directory
fsck: error opening dir "(...)": 2=no such file or directory
fsck: error opening dir "(...)": 2=no such file or directory
fsck: error opening dir "(...)": 2=no such file or directory
fsck: error opening dir "(...)": 2=no such file or directory
fsck: error opening dir "(...)": 2=no such file or directory
fsck: error opening dir "(...)": 2=no such file or directory
fsck summary: 10 corrupt files

Looking into the encrypted directory after that showed that the encrypted data was missing. This wasn't verified before running "gocryptfs -fsck". Interestingly the directories that lost their content are alphabetically last if sorted by encrypted directory name.

Both filesystems, the root filesystem and the filesystem that hosts the gocryptfs ecrypted directory are ext4.

I can not be sure that this is caused by gocryptfs and not by some underlying filesystem problem, but I think it warents checking if gocryptfs can be dammaged by a filled root file system. For example by not being able to use /tmp?

Best
Matthias

-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gocryptfs depends on:
ii  libc6      2.28-10
ii  libfuse2   2.9.9-1+deb10u1
ii  libssl1.1  1.1.1d-0+deb10u5

gocryptfs recommends no packages.

gocryptfs suggests no packages.

-- no debconf information