linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2] getsecurity/vfs_getxattr cleanup V2
@ 2007-11-01 14:35 David P. Quigley
  2007-11-01 14:40 ` [PATCH 1/2] VFS/Security: Rework inode_getsecurity and callers to return resulting buffer David P. Quigley
  2007-11-01 14:41 ` [PATCH 2/2] VFS: Reorder vfs_getxattr to avoid unnecessary calls to the LSM David P. Quigley
  0 siblings, 2 replies; 10+ messages in thread
From: David P. Quigley @ 2007-11-01 14:35 UTC (permalink / raw)
  To: linux-security-module, linux-fsdevel, jmorris, sds, serue, akpm

This patch series addresses two concerns. Currently when a developer
wishes to obtain a security blob from the LSM he/she has to guess at the
length of the blob being returned. We modify security_inode_getsecurity
to return an appropriately sized buffer populated with the security
information and the length of that buffer. This is similar to the
approach taken by Al Viro for the security_getprocattr hook. 

The second concern that this patch set addresses is that vfs_getxattr
reads the security xattr using inode_getxattr and then proceeds to
clobber it with a subsequent call to the LSM. This is fixed by
reordering vfs_getxattr.

The difference between this patch and version one can be seen in two places.
As per James Morris's suggestion function declarations that were split into
multiple lines because they were larger than 80 characters in length have been
merged into one line. Second as per Serge's comments security_inode_getsecurity
and the LSM hook inode_getsecurity take a bool to indicate if the function
should allocate the buffer and return the length or just return the length.  

This patch should apply on top of 2.6.24-rc1 and will definitely apply on git
commit hash ec3b67c11df42362ccda81261d62829042f223f0

If all concerns have been addressed I would propose the patches be added into -mm.


^ permalink raw reply	[flat|nested] 10+ messages in thread
* [RFC 0/2] getsecurity/vfs_getxattr cleanup
@ 2007-10-22 19:06 David P. Quigley
  2007-10-22 19:11 ` [PATCH 2/2] VFS: Reorder vfs_getxattr to avoid unnecessary calls to the LSM David P. Quigley
  0 siblings, 1 reply; 10+ messages in thread
From: David P. Quigley @ 2007-10-22 19:06 UTC (permalink / raw)
  To: linux-security-module, linux-fsdevel, jmorris, sds

This patch series addresses two concerns. Currently when a developer
wishes to obtain a security blob from the LSM he/she has to guess at the
length of the blob being returned. We modify security_inode_getsecurity
to return an appropriately sized buffer populated with the security
information and the length of that buffer. This is similar to the
approach taken by Al Viro for the security_getprocattr hook. 

The second concern that this patch set addresses is that vfs_getxattr
reads the security xattr using inode_getxattr and then proceeds to
clobber it with a subsequent call to the LSM. This is fixed by
reordering vfs_getxattr.

The series applies on top of 2.6.23 aka git hash
bbf25010f1a6b761914430f5fca081ec8c7accd1


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2007-11-01 22:47 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-01 14:35 [PATCH 0/2] getsecurity/vfs_getxattr cleanup V2 David P. Quigley
2007-11-01 14:40 ` [PATCH 1/2] VFS/Security: Rework inode_getsecurity and callers to return resulting buffer David P. Quigley
2007-11-01 20:58   ` James Morris
2007-11-01 22:43   ` Serge E. Hallyn
2007-11-01 14:41 ` [PATCH 2/2] VFS: Reorder vfs_getxattr to avoid unnecessary calls to the LSM David P. Quigley
2007-11-01 20:58   ` James Morris
2007-11-01 22:47   ` Serge E. Hallyn
  -- strict thread matches above, loose matches on Subject: below --
2007-10-22 19:06 [RFC 0/2] getsecurity/vfs_getxattr cleanup David P. Quigley
2007-10-22 19:11 ` [PATCH 2/2] VFS: Reorder vfs_getxattr to avoid unnecessary calls to the LSM David P. Quigley
2007-10-23 23:42   ` James Morris
2007-10-25 23:43     ` Serge E. Hallyn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).