Re: 2.6.6-mm1

Christoph Hellwig <hch@infradead.org> wrote:
>
> > +hugetlb_shm_group-sysctl-patch.patch
> > 
> >  Add /proc/sys/vm/hugetlb_shm_group: this holds the group ID of users who may
> >  allocate hugetlb shm segments without CAP_IPC_LOCK.  For Oracle.
> > 
> > +mlock_group-sysctl.patch
> > 
> >  /proc/sys/vm/mlock_group: group ID of users who can do mlock() without
> >  CAP_IPC_LOCK.  Not sure that we need this.
> 
> These two just introduced a subtile behaviour change during stable series,
> possibly (not likely) leading to DoS opportunities from applications running
> as gid 0.

mlock_group is likely to go away.

Is an unprivileged user likely to have gid 0?   Easy enough to fix, anyway.

--- 25/fs/hugetlbfs/inode.c~hugetlb_shm_group-sysctl-gid-0-fix	Mon May 10 14:57:31 2004
+++ 25-akpm/fs/hugetlbfs/inode.c	Mon May 10 14:58:59 2004
@@ -722,8 +722,11 @@ static unsigned long hugetlbfs_counter(v
 
 static int can_do_hugetlb_shm(void)
 {
-	return likely(capable(CAP_IPC_LOCK) ||
-			in_group_p(sysctl_hugetlb_shm_group));
+	if (capable(CAP_IPC_LOCK))
+		return 1;
+	if (sysctl_hugetlb_shm_group == 0)
+		return 0;
+	return in_group_p(sysctl_hugetlb_shm_group);
 }
 
 struct file *hugetlb_zero_setup(size_t size)

>  Really, with capabilities first and now selinux we have moved
> away from treating uid 0 special, so introducing special casing of a gid
> now is more than just braindead.

Capabilities are broken and don't work.  Nobody has a clue how to provide
the required services with SELinux and nobody has any code and we need the
feature *now* before vendors go shipping even more ghastly stuff.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/