Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

sshfs date bug #4

Open
thomasmerz opened this issue Jan 27, 2023 · 8 comments
Open

sshfs date bug #4

thomasmerz opened this issue Jan 27, 2023 · 8 comments

Comments

@thomasmerz
Copy link

thomasmerz commented Jan 27, 2023 •
edited
Loading

Hi @deadbeefsociety and @h4sh5,

I really understand and I have the utmost understanding that unless I'm including a pull request or are reporting a critical issue, I might or even will probably not get a response for my low-impact issues.
But maybe you find my BUG interesting enough to have a look at it.

This bug has already been on libfuse#44 but has been closed unsolved.

🇩🇪  root@ubuntu-cx11-02:~/mnt/hetzner # touch -t 197001010000 1970; stat 1970 # results in future date --> wrong!
  File: 1970
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 29h/41d	Inode: 6898501     Links: 1
Access: (0644/-rw-r--r--)  Uid: (194581/ hetzner)   Gid: (194581/ hetzner)
Access: 2106-02-07 06:28:16.000000000 +0100
Modify: 2106-02-07 06:28:16.000000000 +0100
Change: 2106-02-07 06:28:16.000000000 +0100
 Birth: -
🇩🇪  root@ubuntu-cx11-02:~/mnt/hetzner # touch -t 197001010100 1970; stat 1970 # results in now --> wrong!
  File: 1970
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 29h/41d	Inode: 6898501     Links: 1
Access: (0644/-rw-r--r--)  Uid: (194581/ hetzner)   Gid: (194581/ hetzner)
Access: 2023-01-27 16:42:30.000000000 +0100
Modify: 2023-01-27 16:42:30.000000000 +0100
Change: 2023-01-27 16:42:30.000000000 +0100
 Birth: -
root@ubuntu-cx11-02:~/mnt/hetzner # touch -t 197001010101 1970; stat 1970 # results in 1st day of 1970 but 01:01 am (all right)
  File: 1970
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 29h/41d	Inode: 6898501     Links: 1
Access: (0644/-rw-r--r--)  Uid: (194581/ hetzner)   Gid: (194581/ hetzner)
Access: 1970-01-01 01:01:00.000000000 +0100
Modify: 1970-01-01 01:01:00.000000000 +0100
Change: 1970-01-01 01:01:00.000000000 +0100
 Birth: -
🇩🇪  root@ubuntu-cx11-02:~/mnt/hetzner # touch -t 197001010200 1970; stat 1970 # results in 1st day of 1970 and 02:00 am (all right)
  File: 1970
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 29h/41d	Inode: 6898501     Links: 1
Access: (0644/-rw-r--r--)  Uid: (194581/ hetzner)   Gid: (194581/ hetzner)
Access: 1970-01-01 02:00:00.000000000 +0100
Modify: 1970-01-01 02:00:00.000000000 +0100
Change: 1970-01-01 02:00:00.000000000 +0100
 Birth: -

This happens on Ubuntu 22.04.1 LTS…

SSHFS version 3.7.1
FUSE library version 3.10.5
using FUSE kernel interface version 7.31
fusermount3 version: 3.10.5

and on openSUSE Leap 15.4 with the following versions:

SSHFS version 3.7.2
FUSE library version 3.10.5
using FUSE kernel interface version 7.31
fusermount3 version: 3.10.5

On my Macbook (Ventura 13.1) and these versions…

SSHFS version 2.10
FUSE library version: 2.9.9
fuse: no mount point

it's also wrong with the slight difference, that 197001010100 doesn't results in "now" but in the right date.

I’m really far away from programming, my last programming was some decades ago in my computer science /system programming studies, so maybe I've aroused your interest and you can help me fixing this because I'm in the need to work with these very old timestamps to represent my data from "a long time ago" correct?
@h4sh5
Copy link
Collaborator

h4sh5 commented Feb 21, 2023

This seems problematic for sure, I will have a look. No promises though!

@thomasmerz
Copy link
Author

Thanks for accepting the challenge 😃

@h4sh5
Copy link
Collaborator

h4sh5 commented Feb 21, 2023

Happening in Fedora 36 as well:

SSHFS version 3.7.3
FUSE library version 3.10.5
using FUSE kernel interface version 7.31
fusermount3 version: 3.10.5

$ touch -t 197001010101 1970; stat 1970
  File: 1970
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 0,81	Inode: 5           Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Context: system_u:object_r:fusefs_t:s0
Access: 2106-02-07 07:29:16.000000000 +1000
Modify: 2106-02-07 07:29:16.000000000 +1000
Change: 2106-02-07 07:29:16.000000000 +1000

@thomasmerz
Copy link
Author

Here I have some more Enterprise Linuxes from which I have mounted my home-dir to my Macbook with touch -t 197001010000 1970 via sshfs:

$ stat */1970|grep -E "File|0100"
  File: sles12-sp5-01/1970
Access: 2023-02-21 11:51:42.000000000 +0100
Modify: 2106-02-07 06:28:16.000000000 +0100
Change: 2106-02-07 06:28:16.000000000 +0100
  File: sles15-sp4-01/1970
Access: 2023-02-21 11:51:42.000000000 +0100
Modify: 2106-02-07 06:28:16.000000000 +0100
Change: 2106-02-07 06:28:16.000000000 +0100
  File: tst-rhel-79/1970
Access: 2023-02-21 11:51:43.000000000 +0100
Modify: 2106-02-07 06:28:16.000000000 +0100
Change: 2106-02-07 06:28:16.000000000 +0100
  File: tst-rhel-87/1970
Access: 2023-02-21 11:51:43.000000000 +0100
Modify: 2038-01-19 04:14:07.000000000 +0100
Change: 2038-01-19 04:14:07.000000000 +0100

@h4sh5
Copy link
Collaborator

h4sh5 commented Feb 21, 2023 •
edited
Loading

I think the message/mechanism that's supposed to set file attributes is SSH_FXP_SETSTAT (based on debug output running with -d, it ouputs SETSTAT when I run touch). The spec for that is in IETF here

I added a hex dump debug function to dump out the iov and it shows this dump when I run touch -t 197001010102 remote/tmp/1970

[sftp_request_build] iov:
   0: 00 00 00 09 2f 74 6d 70 2f 31 39 37 30 00 00 00 |..../tmp/1970...|
  16: 08 ff ff 81 e8 ff ff 81 e8                      |.........|
[00014] SETSTAT len:34 count:1
  [00014]         STATUS       28bytes (1ms)

When I run touch -t 197101010102 remote/tmp/1971 :

[sftp_request_build] iov:
   0: 00 00 00 09 2f 74 6d 70 2f 31 39 37 31 00 00 00 |..../tmp/1971...|
  16: 08 01 e0 b5 68 01 e0 b5 68                      |....h...h|
[00034] SETSTAT len:34 count:1

This is the difference:

$ ls --full-time  remote/tmp/1971
-rw-r--r--. 1 root root 0 1971-01-01 01:02:00.000000000 +1000 remote/tmp/1971

$ ls --full-time  remote/tmp/1970
-rw-r--r--. 1 root root 0 2106-02-07 07:30:16.000000000 +1000 remote/tmp/1970

From a first glance of the hex dumps, it seems the 1970 date (ff ff 81 e8, not sure if I got the right offset of bytes) is an overflowed/underflowed negative number while the 1971 date 01 e0 b5 68 is normal.

File attributes (ATTR) are described in section 7

byte   SSH_FXP_SETSTAT
uint32 request-id
string path [UTF-8]
ATTRS  attrs

00 00 00 09 2f 74 6d 70 2f 31 39 37 30 00 00 00 
08 ff ff 81 e8 ff ff 81 e8  

byte SSH_FXP_SETSTAT -> 00 00 00 09 (just 09)
string path -> 2f 74 6d 70 2f 31 39 37 30 (/tmp/1970)
ATTRS  attrs -> 00 00 00 08 ff ff 81 e8 ff ff 81 e8  (?)

I have pushed the hex dumping when debugging (-d) change to main, @thomasmerz you can play around with the timestamps and see if you can find anything else interesting. My suspicion is that per the SFTP spec section 7.7:

All times are represented as seconds from Jan 1, 1970 in UTC.

there may be some sort of off-by-N bug in either SSHFS or SFTP or FUSE that made timestamps represented as seconds from Jan 1 1970 00:00:01 / 00:01:00 /.. or something like that and your edge cases threw them off.

It's not a critical bug, but it might have interesting security implications if time is used to actually do something important over SSHFS.

I'll leave this open as I keep digging a bit more.

@thomasmerz
Copy link
Author

I already played around a little bit with the timestamps and I think I found already interesting timestamps as listed above… 🤔 (resulting in now and a future date)

@thomasmerz
Copy link
Author

@h4sh5 , have you had the time to investigate further on this?

@thomasmerz
Copy link
Author

I've another example (caused by a typo when touching a file in a bad script) - local file:

$ stat *txt
  File: *.txt
  Size: 0             Blocks: 0          IO Block: 4096   regular empty file
Device: 829h/2089d    Inode: 541135566   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  thomas)   Gid: (  100/   users)
Access: 1914-01-01 00:00:00.000000000 +0100
Modify: 1914-01-01 00:00:00.000000000 +0100
Change: 2023-04-11 18:09:58.355975695 +0200
 Birth: 2023-04-11 18:09:58.355975695 +0200

vs. remote:

$ stat *txt
  File: *.txt
  Size: 0             Blocks: 0          IO Block: 4096   regular empty file
Device: c3h/195d    Inode: 1845027     Links: 1
Access: (0644/-rw-r--r--)  Uid: (12345/ 23456)   Gid: (12345/ 23456)
Access: 2050-02-06 06:28:16.000000000 +0100
Modify: 2050-02-06 06:28:16.000000000 +0100
Change: 2050-02-06 06:28:16.000000000 +0100
 Birth: -

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@thomasmerz @h4sh5