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>] [day] [month] [year] [list]
Message-Id: <120124221424f4f1daa3ab344ab8e4d4ba1bae21070f@nudt.edu.cn>
Date:	Tue, 24 Jan 2012 22:14:24 +0800
From:	"Li Wang" <liwang@...t.edu.cn>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	john.johansen@...onical.com, dustin.kirkland@...zang.com,
	"Cong Wang" <xiyou.wangcong@...il.com>, ecryptfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	"Tyler Hicks" <tyhicks@...onical.com>
Subject: Re:[PATCH 2/3 v2] eCryptfs: Check inode changes in setattr

Hi Tyler,
  We think that is good, except it is not very elegant to invoke 
inode_newsize_ok with the ecryptfs (upper) inode and lower size, nevertheless, we donot have other better choices and it is wrapped in 
ecryptfs_inode_newsize_ok...
  In a word, we are with you.

Cheers,
Li Wang





---------- Origin message ----------
>From:"Tyler Hicks" <tyhicks@...onical.com>
>To:ecryptfs@...r.kernel.org, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
>Subject:[PATCH 2/3 v2] eCryptfs: Check inode changes in setattr
>Date:2012-01-24 15:37:32

Most filesystems call inode_change_ok() very early in ->setattr(), but
eCryptfs didn't call it at all. It allowed the lower filesystem to make
the call in its ->setattr() function. Then, eCryptfs would copy the
appropriate inode attributes from the lower inode to the eCryptfs inode.

This patch changes that and actually calls inode_change_ok() on the
eCryptfs inode, fairly early in ecryptfs_setattr(). Ideally, the call
would happen earlier in ecryptfs_setattr(), but there are some possible
inode initialization steps that must happen first.

Since the call was already being made on the lower inode, the change in
functionality should be minimal, except for the case of a file extending
truncate call. In that case, inode_newsize_ok() was never being
called on the eCryptfs inode. Rather than inode_newsize_ok() catching
maximum file size errors early on, eCryptfs would encrypt zeroed pages
and write them to the lower filesystem until the lower filesystem's
write path caught the error in generic_write_checks(). This patch
introduces a new function, called ecryptfs_inode_newsize_ok(), which
checks if the new lower file size is within the appropriate limits when
the truncate operation will be growing the lower file. 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ