On Mon, 2009-07-27 at 22:55 +0100, Daniel P. Berrange wrote: > On Thu, Jul 23, 2009 at 09:00:18PM -0400, john cooper wrote: > > I've incorporated feedback received on the > > prior version into the patch below. > > > > The host mount point for hugetlbfs is queried by > > default from /proc/mounts unless overridden in > > qemu.conf via: > > > > hugepage_mount = "<path_to_mount_point>" > > > > This should make the concern of establishing > > a mount point path convention a non-issue for > > the general case while still allowing the same > > to be deterministically set if needed. > > In light of what Chris said about extended attribute support > for SELinux I think we, sadly, have no choice by to mount > a new instance of hugetlbfs per VM, labelled with the context > of that VM. The problem is that this doesn't really fit into > the internal architecture we have in the slightest. The > SELinux support we have is focused around re-labelling > existing resources. > > This hugetlbfs support implies that the SELinux driver is > altering our command line arg generator, which is not an > easy thing for us to support, given the code flow here. > We might have to resort to sick gross hacks.... unless the > kernel guys think its easy to add extended attribute support > to hugetlbfs in no time at all. There is a vfs fallback for setxattr of the security.* namespace to the security module, which would work for hugetlbfs if not for the fact that policy defines it as a genfscon-labeled filesystem. We only started prohibiting setxattr on genfscon-labeled filesystems in 2.6.30; prior to that we only did that for mountpoint-labeled filesystems. I can actually chcon a file in a hugetlbfs mount on 2.6.29. To convert hugetlbfs to fully support labeling we'd need hugetlbfs_mknod() to call security_inode_init_security() to set up new inode security labels, just like shmem_mknod() does for tmpfs. And then we'd need to switch over the policy from genfscon to fs_use_trans. -- Stephen Smalley National Security Agency -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list