invalid file times with overlayroot and encrypted home

Bug #1636890 reported by Kevin
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-initramfs-tools
Invalid
Medium
Unassigned
linux (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I did a basic install of 16.04.1 server amd64 (accepting most of the defaults) but selected to have the home area of the initial user encrypted. Then log on as that user and create some files. Next enable overlayroot by adding a /etc/overlayroot.local.conf with 'overlayroot=tmpfs' and reboot.

After rebooting and logging in as the user, the previously created files are there but the timestamps are wrong. 'stat' gives the times as:
Access: 1970-01-01 01:00:00.000000000 +01:00
Modify: 1970-01-01 01:00:00.000000000 +01:00
Change: 1970-01-01 01:00:00.000000000 +01:00
---
AlsaDevices:
 total 0
 crw-rw----+ 1 root audio 116, 1 Nov 14 15:46 seq
 crw-rw----+ 1 root audio 116, 33 Nov 14 15:46 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
DistroRelease: Ubuntu 16.04
EcryptfsInUse: Yes
HibernationDevice: RESUME=UUID=05dc7e53-33c6-4784-9d1e-230db315c1f8
InstallationDate: Installed on 2016-11-14 (0 days ago)
InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
IwConfig: Error: [Errno 2] No such file or directory
MachineType: Supermicro Super Server
Package: linux (not installed)
PciMultimedia:

ProcFB: 0 astdrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-47-generic root=UUID=a933e18e-10d8-417d-8154-a0a16a691ae4 ro
ProcVersionSignature: Ubuntu 4.4.0-47.68-generic 4.4.24
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-47-generic N/A
 linux-backports-modules-4.4.0-47-generic N/A
 linux-firmware 1.157.4
RfKill: Error: [Errno 2] No such file or directory
Tags: xenial
Uname: Linux 4.4.0-47-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 12/17/2015
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 2.0
dmi.board.asset.tag: Default string
dmi.board.name: X10DRD-i
dmi.board.vendor: Supermicro
dmi.board.version: 1.00
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 17
dmi.chassis.vendor: Supermicro
dmi.chassis.version: 0123456789
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2.0:bd12/17/2015:svnSupermicro:pnSuperServer:pvr0123456789:rvnSupermicro:rnX10DRD-i:rvr1.00:cvnSupermicro:ct17:cvr0123456789:
dmi.product.name: Super Server
dmi.product.version: 0123456789
dmi.sys.vendor: Supermicro

Revision history for this message
Kevin (kevin-dem) wrote :

I forgot to mention that I had performed an 'apt-get dist-upgrade' after the install which resulted in the kernel being 4.4.0-45-generic

Revision history for this message
Scott Moser (smoser) wrote :

Hi,
This seems not likely related specifically to cloud-initramfs-tools, but rather to the kernel filesystem. I'm adding a kernel package task.

the kernel team may ask you for more information.

Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1636890

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Kevin (kevin-dem) wrote : CRDA.txt

apport information

tags: added: apport-collected xenial
description: updated
Revision history for this message
Kevin (kevin-dem) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Kevin (kevin-dem) wrote : JournalErrors.txt

apport information

Revision history for this message
Kevin (kevin-dem) wrote : Lspci.txt

apport information

Revision history for this message
Kevin (kevin-dem) wrote : Lsusb.txt

apport information

Revision history for this message
Kevin (kevin-dem) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Kevin (kevin-dem) wrote : ProcEnviron.txt

apport information

Revision history for this message
Kevin (kevin-dem) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Kevin (kevin-dem) wrote : ProcModules.txt

apport information

Revision history for this message
Kevin (kevin-dem) wrote : UdevDb.txt

apport information

Revision history for this message
Kevin (kevin-dem) wrote : WifiSyslog.txt

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Seth Forshee (sforshee) wrote :

I've reproduced this in a vm (more or less, my timestamps are different but still wrong, but I'm guessing that's just due to different timezone configurations).

Some relevant entries from /proc/mountinfo:

24 26 8:1 / /media/root-ro ro,relatime shared:2 - ext4 /dev/sda1 ro,data=ordered
25 26 0:20 / /media/root-rw rw,relatime shared:3 - tmpfs tmpfs-root rw
26 0 0:21 / / rw,relatime shared:1 - overlayfs overlayroot rw,lowerdir=/media/root-ro,upperdir=/media/root-rw//overlay,workdir=/media/root-rw//overlay-workdir
101 26 0:43 / /home/ubuntu rw,nosuid,nodev,relatime shared:80 - ecryptfs /home/ubuntu/.Private rw,ecryptfs_fnek_sig=8123544c12013d26,ecryptfs_sig=de2cdf716df70cde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs

So, the original root is mounted at /media/root-ro, and there's a tmpfs at /media/root-rw which holds the overlayfs work and upper directories. / is an overlayfs mount, and the encrypted files for my homedir are stored in /home/ubuntu/.Private (which is a symlink to /home/.ecryptfs/ubuntu/.Private).

What I see is that only the files in the root of the ecryptfs mount which come from the lowerdir have incorrect timestamps. A directory I created before enabling overlayroot has the correct timestamp, and two files in that directory also have correct timestamps. New files created in the directory (which thus exist only in the upperdir) have the correct timestamp, however if I modify a file created before overlayroot was enabled the timestamp remains incorrect, and even does so if I remove and create a file of the same name.

The timestamps in /home/.ecruptfs/ubuntu/.Private are all correct. I'm guessing that ecryptfs takes timestamps from the lower directory inodes, so my hunch is that this is a problem in ecryptfs.

Revision history for this message
Seth Forshee (sforshee) wrote :

I think I see what's going on. Ecryptfs copies up attributes from the lower filesystem's inode directly. However the practice of overlayfs is to only copy up i_uid, i_gid, and i_mode from the lower inode into the overlayfs inode, and to fetch other attributes from the lower inode on getattr.

The pattern I'm seeing is that inodes that overlayfs has "copied up" from the lowerdir to the upperdir show up okay. I suspect then that it's the vfs updating the timestamps in the overlayfs inodes whenever the event happens that triggered the copy-up.

Revision history for this message
Seth Forshee (sforshee) wrote :

One correction to comment #16 - I'm now finding cases where files not copied up still have the correct timestamps in ecryptfs, and all the timestamps match those in the lower inode. So I'm not sure why the overlayfs inodes seem to have the correct timestamps sometimes.

Scott Moser (smoser)
Changed in cloud-initramfs-tools:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Scott Moser (smoser) wrote :

Marking this Invalid on cloud-initramfs-tools. It doesn't seem likely that there is much we can do there.

Changed in cloud-initramfs-tools:
status: Confirmed → Invalid
Brad Figg (brad-figg)
tags: added: cscc
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.