|| ||Andrew Morton <akpm-AT-osdl.org>|
|| ||Christoph Hellwig <hch-AT-infradead.org>|
|| ||Re: 2.6.6-mm1|
|| ||Mon, 10 May 2004 15:02:03 -0700|
Christoph Hellwig <firstname.lastname@example.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) ||
+ 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 email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to post comments)