ctlsock crashes with leading slash in EncryptPath

[jlippuner]

When I send a request like {"EncryptPath":"/foo"} to the control socket, it crashes (subsequent requests result in nc: unix connect failed: Connection refused). Without a leading slash everything seems to work.

I'm sending requests with netcat-openbsd as
echo '{"EncryptPath":"/foo"}' | nc -U ctlsock | jq -r '.Result'

[rfjakob]

Yes, I can reproduce this, the backtrace is pasted below. Thanks for the report!
PS: If gocryptfs panics, it will leave the backtrace in /tmp/gocryptfs_paniclog.XYZ. The content should look like what I pasted below.

panic: Padding zero-length string makes no sense

goroutine 20 [running]:
panic(0x5e6d80, 0xc420240250)
	/usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/rfjakob/gocryptfs/internal/nametransform.pad16(0xc42023dbc8, 0x0, 0x20, 0xc42023dbc8, 0x0, 0x20)
	/home/jakob/src/github.com/rfjakob/gocryptfs/internal/nametransform/pad16.go:14 +0x17a
github.com/rfjakob/gocryptfs/internal/nametransform.(*NameTransform).EncryptName(0xc42001c630, 0xc420240248, 0x0, 0xc420246480, 0x10, 0x11, 0x0, 0x0)
	/home/jakob/src/github.com/rfjakob/gocryptfs/internal/nametransform/names.go:71 +0x79
github.com/rfjakob/gocryptfs/internal/nametransform.(*NameTransform).EncryptPathDirIV(0xc42001c630, 0xc420240248, 0x4, 0x7ffdab270159, 0x2e, 0xc42024e200, 0xc41ffed7e4, 0xc42023de20, 0x4198ce)
	/home/jakob/src/github.com/rfjakob/gocryptfs/internal/nametransform/diriv.go:114 +0x279
github.com/rfjakob/gocryptfs/internal/fusefrontend.(*FS).encryptPath(0xc42001ea80, 0xc420240248, 0x4, 0x30, 0x60b720, 0x1, 0xc420250360)
	/home/jakob/src/github.com/rfjakob/gocryptfs/internal/fusefrontend/names.go:48 +0x96
github.com/rfjakob/gocryptfs/internal/fusefrontend.(*FS).EncryptPath(0xc42001ea80, 0xc420240248, 0x4, 0xc420262027, 0xc42023dec8, 0x4c75d2, 0xc42024e1e0)
	/home/jakob/src/github.com/rfjakob/gocryptfs/internal/fusefrontend/ctlsock_interface.go:13 +0x3f
github.com/rfjakob/gocryptfs/internal/ctlsock.(*ctlSockHandler).handleRequest(0xc4200130a0, 0xc420246420, 0xc420248050)
	/home/jakob/src/github.com/rfjakob/gocryptfs/internal/ctlsock/ctlsock_serve.go:112 +0x24e
github.com/rfjakob/gocryptfs/internal/ctlsock.(*ctlSockHandler).handleConnection(0xc4200130a0, 0xc420248050)
	/home/jakob/src/github.com/rfjakob/gocryptfs/internal/ctlsock/ctlsock_serve.go:96 +0x186
created by github.com/rfjakob/gocryptfs/internal/ctlsock.(*ctlSockHandler).acceptLoop
	/home/jakob/src/github.com/rfjakob/gocryptfs/internal/ctlsock/ctlsock_serve.go:67 +0x88

[jlippuner]

Hmm, I don't see a backtrace in /tmp/gocryptfs_paniclog.XYZ. It also crashes with trailing slashes in the file name.

[rfjakob]

"XYZ" is a random number, for example I just got "/tmp/gocryptfs_paniclog.658063417"

[rfjakob]

The paths that get passed into the control socket are now canonicalized as the Linux kernel would do when it passes a path to us. This fixes the panics. If the path has been non-canonical, you get a message in the WarnText JSON element:

$ echo '{"EncryptPath":"/../../..//foo"}' | nc -U sock
{"Result":"L7stFKYWZUPZUZt8PwaKUA==","ErrNo":0,"ErrText":"","WarnText":"Non-canonical input path \"/../../..//foo\" has been interpreted as \"foo\""}

[rfjakob]

However, I noticed that the socket file is not deleted on exit. This is tracked in #67 and will be fixed shortly (probably tomorrow).

[rfjakob]

#67 has been fixed in 6af725f

[jlippuner]

Thanks for the quick fix! Yes, I had to delete ctlsock manually after it crashed. Thanks for fixing that too!

I don't see any panic logs of the form /tmp/gocryptfs_paniclog.* or indeed anything like /tmp/gocryptfs*.

[rfjakob]

FYI I have just added a small interactive shell script for path encryption: https://github.com/rfjakob/gocryptfs/blob/master/contrib/ctlsock-encrypt.bash