Problems with file timestamps and ShiftFS on unprivileged containers?

Hi,

it seems I have problems with file-timestamps in conjunction
with ShiftFS + unprivileged containers.

When copying files with “cp -p”, the source file shouldn’t be newer than the duplicate:

To reproduce, first I run the command with privileged containers, successfully:

lxc config set d1 security.privileged=true
lxc restart d1
lxc exec d1 -- bash -c "touch a; cp -p a b; if [ a -nt b ]; then echo FAIL; else echo OK; fi; rm a b"
# Output: OK

With unprivileged it fails:

lxc config set d1 security.privileged=false
lxc restart d1
lxc exec d1 -- bash -c "touch a; cp -p a b; if [ a -nt b ]; then echo FAIL; else echo OK; fi; rm a b"
# Output: FAIL

The hosts are Gentoo-Linux, kernel 5.4 with lxd 4.0.3, Shiftfs, ZFS 0.8.
I tried with Debian and Gentoo-Containers.

Is this a bug or is it config problem on my end?

__Update: ___

A stat a b outputs this, when running privileged:

  File: a
  Size: 0               Blocks: 1          IO Block: 131072 regular empty file
Device: 50h/80d Inode: 66000       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-11-07 20:10:28.072665559 +0000
Modify: 2020-11-07 20:10:28.072665559 +0000
Change: 2020-11-07 20:10:28.072665559 +0000
 Birth: -
  File: b
  Size: 0               Blocks: 1          IO Block: 131072 regular empty file
Device: 50h/80d Inode: 66001       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-11-07 20:10:28.072665559 +0000
Modify: 2020-11-07 20:10:28.072665559 +0000
Change: 2020-11-07 20:10:28.075998611 +0000

When running unprivileged:

  File: a
  Size: 0               Blocks: 1          IO Block: 131072 regular empty file
Device: 50h/80d Inode: 65999       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-11-07 20:10:30.789102206 +0000
Modify: 2020-11-07 20:10:30.789102206 +0000
Change: 2020-11-07 20:10:30.789102206 +0000
 Birth: -
  File: b
  Size: 0               Blocks: 1          IO Block: 131072 regular empty file
Device: 50h/80d Inode: 66000       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-11-07 20:10:30.000000000 +0000
Modify: 2020-11-07 20:10:30.000000000 +0000
Change: 2020-11-07 20:10:30.792435256 +0000
 Birth: -

Looks like the sub-second-information went missing.

Thanks
Michael

@brauner @sforshee shiftfs bug?

To confirm I just tested the problem with the ShiftFS-module disabled: In this case everything works without error.

Yeah, this seems like a shiftfs bug though I’m not yet sure where the bug is located.

Hi,

Don’t know if this helps, but I tinkered around a bit and found out that setting a
filetime with the futimens-glibc-call does zero the nanoseconds, when a arbitrary
value is set in the timespec.tv_nsec-field. (This is probably what cp -p
does)

But when setting the tv_nsec to the UTIME_NOW constant, the nanonseconds
are also updated (e.g. what touch would do)

(Source of test is at shiftfs-ts-test/t.c at main · hxx-fetch/shiftfs-ts-test (github.com))