On Fri, 2005-07-15 at 11:28 -0400, Stephen Smalley wrote: > This is a request for comments on the below patch that modifies the VFS > setxattr, getxattr, and listxattr code to fall back to the security > module for security xattrs if the filesystem does not support xattrs > natively. This allows security modules to export the incore inode > security label information to userspace even if the filesystem does not > provide xattr storage, and eliminates the need to individually patch > various pseudo filesystem types to provide such access (note that this > patch removes the existing xattr code from devpts and tmpfs as it is > then no longer needed). This patch was written by a colleague who > prefers to remain anonymous. > > An optional variant would be to only provide such fallbacks for getxattr > (and possibly listxattr, so that any programs that first query for the > list of attributes will see the security xattr name), but not setxattr. > That seems safer (although policy can always prevent setxattr on > particular filesystem types), but would require retaining the special > handlers in devpts and tmpfs, as they need to support setxattr, and > patching any other pseudo filesystems that need to support setxattr. > Not sure ultimately what will be the right way to handle labeling of > filesystems like sysfs, i.e. exporting setxattr and letting early > userspace label it or having the kernel internally assign labels based > on some mapping. Hi, I haven't seen any discussion of the optional variant described above, which I actually expected to provoke the most discussion. Any strong opinions on it? -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Mon Jul 25 2005 - 08:23:20 PDT