Messages in this thread | | | Date | Wed, 12 May 2004 04:44:25 +0200 | From | Andrea Arcangeli <> | Subject | Re: 2.6.6-mm1 |
| |
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/
| |