Bug 1389545

Summary:	Code: System error: Relative paths to --tmpfs option
Product:	Red Hat Enterprise Linux 7	Reporter:	Chris Evich <cevich>
Component:	docker	Assignee:	Antonio Murdaca <amurdaca>
Status:	CLOSED ERRATA	QA Contact:	atomic-bugs <atomic-bugs>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	7.2	CC:	amurdaca, lsm5, lsu, santiago
Target Milestone:	rc	Keywords:	Extras
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-02 00:11:21 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Evich 2016-10-27 20:36:06 UTC

Description of problem:
The docker client should better validate --tmpfs paths are absolute,
so that consistent and clear errors are returned when the path is relative.

Version-Release number of selected component (if applicable):
docker 1.10 (and probably 1.12)

How reproducible:
always increasing time vs path length

Steps to Reproduce:
1. # docker run -it --tmpfs . docker.io/fedora bash
2. # docker run -it --tmpfs ..///.///././ docker.io/fedora bash
3. # docker run -it --tmpfs ..///.///././/././././././..///../..//././././././././././././././././..////./././././///./././././../..///../.././../..///.///././/././././././..///../..//././././././././././././././././..////./././././///./././././../..///../.././../..///.///././/././././././..///../..//././././././././././././././././..////./././././///./././././../..///../.././../..///.///././/././././././..///../..//././././././././././././././././..////./././././///./././././../..///../.././../..///.///././/././././././..///../..//././././././././././././././././..////./././././///./././././../..///../.././../..///.///././/././././././..///../..//././././././././././././././././..////./././././///./././././../..///../.././../..///.///././/././././././..///../..//././././././././././././././././..////./././././///./././././../..///../.././../..///.///././/././././././..///../..//././././././././././././././././..////./././././///./././././../..///../.././../..///.///././/././././././..///../..//././././././././././././././././..////./././././///./././././../..///../.././../..///.///././/././././././..///../..//././././././././././././././././..////./././././///./././././../..///../.././../..///.///././/././././././..///../..//././././././././././././././././..////./././././///./././././../..///../.././../ docker.io/fedora bash

Actual results:
(something similar to)
Timestamp: 2016-10-27 19:17:30.350683572 +0000 UTC
Code: System error

Message: chmod /: operation not permitted

Frames:
---
0: setupRootfs
Package: github.com/opencontainers/runc/libcontainer
File: rootfs_linux.go@41
---
1: Init
Package: github.com/opencontainers/runc/libcontainer.(*linuxStandardInit)
File: standard_init_linux.go@59
---
2: StartInitialization
Package: github.com/opencontainers/runc/libcontainer.(*LinuxFactory)
File: factory_linux.go@247
---
3: initializer
Package: github.com/docker/docker/daemon/execdriver/native
File: init.go@35
---
4: Init
Package: github.com/docker/docker/pkg/reexec
File: reexec.go@26
---
5: main
Package: main
File: docker.go@20
---
6: main
Package: runtime
File: proc.go@188
---
7: goexit
Package: runtime
File: asm_amd64.s@1998
docker: Error response from daemon: Cannot start container 43851ec3bde299730fda2ec139ebd06f885f76a5c7c3da2a6e5e7c69a5762d0c: [9] System error: invalid character 'o' in literal true (expecting 'r').

(exit code 125)

Expected results:
A nice error mesage like, "must pass an absolute path to --tmpfs"

Additional info:
The actual backtrace seems to vary depending on the size/complexity of the relative path.  Also, the longer the path is, the longer it takes docker to process it.  The time increase does not seem linear, so given a sufficiently long relative path, it may be possible to block up the client for quite a while.  Though this is an extreme corner-case, in all instances the final error message doesn't appear to reflect the actual problem (in simple terms).

Comment 2 Antonio Murdaca 2016-10-27 21:26:29 UTC

Fedora has likely the same issue, I'll clone the bug after I investigate it.

Comment 3 Chris Evich 2016-10-28 13:25:03 UTC

Oops, forgot my m8 already had a bug on this:

https://bugzilla.redhat.com/show_bug.cgi?id=1344132

Same cause, but his is more about the error message.  I think if the relative path validation is fixed with a sensible error, both bugs can be resolved.  Though closing one for the other to keep the problem consolidated is fine too.

Comment 4 Antonio Murdaca 2017-01-14 15:48:52 UTC

Reported upstream https://github.com/docker/docker/issues/30166

Comment 5 Antonio Murdaca 2017-01-25 08:16:36 UTC

Fixed in docker-1.13 branch by https://github.com/projectatomic/docker/commit/eb54cdd87f3770d6f173052dc7ce79d2020bda12

Comment 7 Luwen Su 2017-07-22 16:14:53 UTC

In docker-1.12.6-48.git0fdc778.el7.x86_64, these errors are those below separately

Digest: sha256:b27b4c551b1d06be25a3c76c1a9ceefd7ff189f6f8b1711d3e4b230c2081bff3
/usr/bin/docker-current: Error response from daemon: invalid header field value "oci runtime error: container_linux.go:247: starting container process caused \"process_linux.go:364: container init caused \\\"rootfs_linux.go:94: reopening /dev/null inside container caused \\\\\\\"Failed to open /dev/null - open /dev/null: permission denied\\\\\\\"\\\"\"\n".


/usr/bin/docker-current: Error response from daemon: invalid header field value "oci runtime error: container_linux.go:247: starting container process caused \"process_linux.go:364: container init caused \\\"rootfs_linux.go:90: jailing process inside rootfs caused \\\\\\\"pivot_root invalid argument\\\\\\\"\\\"\"\n".


/usr/bin/docker-current: Error response from daemon: invalid header field value "oci runtime error: container_linux.go:247: starting container process caused \"process_linux.go:339: running prestart hook 3 caused \\\"error running hook: exit status 1, stdout: , stderr: \\\"\"\n".

Comment 9 errata-xmlrpc 2017-08-02 00:11:21 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2344