Messages in this thread | | | Date | Sat, 15 May 2004 04:43:36 +0200 | From | Andrea Arcangeli <> | Subject | Re: 2.6.6-mm2 |
| |
On Fri, May 14, 2004 at 01:58:49PM -0700, Chris Wright wrote: > gives the feel of cleaner hack), and is runtime safe (unless you care
what makes no sense to me is the "cleaner hack" approch. Since this is a dirty hack anyways, trying to make it cleaner seems quite pointless, we should keep it simple and localized instead, so it can be deleted with minimal effort. Having more than 1 hack (i.e. more than 1 sysctl) for this as well seems pointless. Dealing with the groups as well seems overkill and not needed.
The question is is if what you are proposing could be a long term solution or not. If it cannot be a long term solution, then going with a single disable_cap_mlock simplest of all hack is the best from my point of view.
> that want safe gpg. In fact, they probably aren't same machine, and I
they can or cannot be in the same machine, but the big question is if the gpg user is "locally" trusted too or not. But this isn't just about gpg. I had to put remap_file_pages under mlock too, not because of the paging, paging of nonlinear VMAs works fine, but the truncate of the nonlinear vmas doesn't work yet correctly. This will be eventually fixed but in the short term I had to keep it under remap_file_pages under mlock since you can mlock memory with remap_file_pages+truncate.
So if one group uses uml and the other group uses oracle, the group approch won't work, only disable_cap_mlock will work. I can very well imagine uml being run as nobody.nogroup or as wwwrun.www.
> [..] Well, anyway for gpg we only want rlimits, and this work is > already done...
correct. - 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/
| |