lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 10 Mar 2016 21:15:06 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Daniel Axtens <dja@...ens.net>
Cc:	linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org,
	viro@...iv.linux.org.uk, miklos@...redi.hu,
	linux-unionfs@...r.kernel.org
Subject: Re: ext4_file_open: Inconsistent encryption contexts (commit
 ff978b09f973) breaking Docker

On Fri, Mar 11, 2016 at 11:44:54AM +1100, Daniel Axtens wrote:
> Hi,
> 
> Trying to run a Docker container on a mainline kernel is failing
> intermittently, in interesting and exciting ways, such as:
> 
> $ docker run -it --rm --env PACKAGE=sinatra npmtest
> operation not permitted
> docker: Error response from daemon: Cannot start container 4fc0120a6389f25241f84527a0d31854806f6fe4fd98d019f790cea0ae7e230b: [10] System error: operation not permitted.
> 
> EXT4-fs warning (device sda2): ext4_file_open:402: Inconsistent encryption contexts: 27842/3691208

This could only happen if the EXT4_ENCRYPT_FL flag is set.  (I assume
you weren't actually trying to use ext4 encryption.)  The flag can't
be set using the FS_IOC_SETFLAGS ioctl.  It can only be set using
EXT4_IOC_SET_ENCRYPTION_POLICY.

The only thing I can think of is that overlayfs is somehow setting or
otherwise corrupting the i_flags.

So if you could try changing the relevant code in ext4_file_open() to
look like this:

	if (ext4_encrypted_inode(dir) &&
	    !ext4_is_child_context_consistent_with_parent(dir, inode)) {
		char tmpbuf[128];

		ext4_warning(inode->i_sb,
			     "Inconsistent encryption contexts: %lu/%lu\n",
			     (unsigned long) dir->i_ino,
			     (unsigned long) inode->i_ino);
		cp = d_path(&filp->f_path, tmpbuf, sizeof(tmpbuf));
		if (!IS_ERR(cp))
			pr_err("pathname: %s\n", cp);
		pr_err("inode flags: %lu\n", EXT4_I(inode)->i_flags);
		WARN_ON(1);
		return -EPERM;
	}

This should give you the stack trace as well as the pathname and inode
flag information.  This will hopefully give us a bit more context
about how this is happening.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ