On Thu, 2008-03-06 at 08:54 -0500, Christoph Hellwig wrote: > On Thu, Mar 06, 2008 at 08:50:22AM -0500, Stephen Smalley wrote: > > In-core only: NFS client gets the file security context for an inode > > from the server and needs to set the in-core security context for its > > inode accordingly. But it does not want to call back to i_op->setxattr > > and try to _set_ the context on the server when it does this. So it > > only calls with the incore flag. > > > > On-disk: NFS server receives a file security context to set on a file > > from the client, and wants to update both the in-core security context > > for the inode and the on-disk xattr. So it calls with the ondisk flag. > > > > It actually only requires a boolean flag. > > Yes, the boolean might be better. > > I still don't quite understand why we would only set the security > context in-core only as this looks like a potential loss of metadata > updates for me. It isn't truly changing the security context - it is notifying the security module on the client side of the security context provided by the server for a given inode. In the case of uids, the nfs client code can directly set the inode->i_uid to the server-provided value from the fattr, but for the inode->i_security, the nfs client code has to call into the security module to set it in-core. Maybe they should be different hooks altogether - just not sure what to call the incore case. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
