Hello, On Wed, Oct 23, 2002 at 12:51:08PM -0400, Stephen Smalley wrote: > > Why are you limited to a single fs? xfs and jfs have xattr support > > out of the box (in 2.4 only jfs is actually in the mainline tree, though) > > Most of our users (and we) happen to use ext[23], so there isn't any point > in migrating SELinux to using EAs until EA implementations are merged into > those filesystems. Also, the EA API lacks support for creating files with > specified security attributes (as opposed to creating and then calling > setxattr to change the attributes, possibly after someone has already > obtained access to the file), so it isn't ideal for our purposes anyway. This is not a shortcoming of the xattr interfaces, they do what they were designed to do. I think the only interfaces suited to setting up things in the way you've described are create, mkdir, mknod, and co. It isn't clear to me how sys_security helps in this situation? -- it would also seem to be non-atomic wrt the inode creation syscalls, in the same way the xattr calls are. The ACL code has to address a similar problem to the one you've described - if a directory has a default ACL set on it, then new children must be created with that ACL. This is implemented by giving filesystems knowledge of the semantics of this attribute, and having them create the ACL along with the inode if need be. cheers. -- Nathan _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed Oct 23 2002 - 23:29:05 PDT