![]() | |||||||||||||
Messages in this thread |
On Tue, May 11, 2004 at 07:23:29AM +0100, Christoph Hellwig wrote: > On Mon, May 10, 2004 at 06:51:18PM -0700, Wim Coekaerts wrote: > > > err, so why did I just merge the hugetlb_shm_group patch? > > > > because of what you mentioned. it takes a long time before that goes > > out, it's not even tested, and it doesn't apply to those 1000's of > > existing systems taht will break on upgrade. exactly what you said, it > > makes it possible to get to a different way smoothly in time. my > > comments were not "we can use it today". > > So it's a hack for legacy oracle versions. nice. and for that we > introduce completely alien concepts like magic groups into the kernel.. I don't see why we're trying to complicate the simple things. I posted a disable_cap_mlock patch several weeks ago, that's the only needed thing. Even if there's an attacker on the machine with disable_cap_mlock == 1, the attacker won't be able to exploit anything, it can only generate a DoS. The cap-mlock is clearly not nearly as security-critical as most other capabilities. There's no reason to get the "hack" any smarter than the disable_cap_mlock approch, any sysctl will be still an hack anyways. The group thing and the differentiation between hugetlbfs users and mlock users (like SHM_LOCK) is a mere attempt to make it more secure, but if you can change the disable_cap_mlock sysctl from 0 to 1 you for sure can also change the hugetlb_shm_group from 0 to 500 and the same for the mlock_group too. Plus I can want to give mlock to the whole system at the same time, not just to a single group, and for that disable_cap_mlock is appropriate. I'm quite confortable to say that disable_cap_mlock can be dropped in 2.8, by that time a replacement solution will be implemented and I don't expect any application learning about the disable_cap_mlock name, they really shouldn't, only the bootup procedure of the OS will know about it and only the login/su will learn about the future replacement. So I believe the best "hack" is to use the simple disable_cap_mlock and to concentrate all the efforts on a more flexible solution involving userspace changes. The one suggested by Andrew by simply dropping the capabilities in login and su sounded very appealing to me. - 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/ | ||||||||||||
| Last update: 2005-03-22 13:03 [from the cache] ©2003-2008 | |||||||||||||