[patch] unprivileged mlock(2)

[Andrey Zonov]

On 8/29/12 8:39 AM, Alan Cox wrote:
> On Tue, Aug 28, 2012 at 4:15 PM, Andrey Zonov <zont at freebsd.org> wrote:
> 
>> On 8/29/12 12:20 AM, Andriy Gapon wrote:
>>> on 28/08/2012 21:07 Bryan Drewery said the following:
>>>> On 8/28/2012 11:37 AM, Andrey Zonov wrote:
>>>>> Hi,
>>>>>
>>>>> We've got RLIMIT_MEMLOCK for years, but this limit is useless, because
>>>>> only root may call mlock(2), and root may raise any limits.
>>>>>
>>>>> I suggest patch that allows to call mlock(2) for unprivileged users.
>>>>> Are there any objections to got it in tree?
>>>>>
>>>>
>>>> FYI, see previous recent thread on this here:
>>>>
>>>> http://lists.freebsd.org/pipermail/freebsd-arch/2012-May/012552.html
>>>> and
>>>> http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012606.html
>>>
>>> Yes, Andrey, I highly suggest that you read those threads completely.
>>>
>>> Here are some observations.
>>>
>>> It doesn't look like mlockall and mlockall(MCL_FUTURE) in particular
>> properly
>>> honor RLIMIT_MEMLOCK.  If this is not fixed, then it would be premature
>> to
>>> enable the privilege for non-privileged users.
>>>
>>
>> This should be surely fixed, but I don't know how.  Any suggestions are
>> welcome.
>>
>>> I am against adding the sysctl knob.  If RLIMIT_MEMLOCK limit is properly
>>> implemented then it is sufficient to effectively deny the privilege (and
>> with
>>> much finer granularity).
>>>
>>
>> Until all bugs around this problem will be fixed, to have such sysctl
>> would be nice, and even keep it turned off to not change default
>> behavior (not like in patch).
>>
>>> When the privilege is allowed to ordinary users, then memorylocked in the
>>> default login.conf would need to be set to something much lower than the
>> current
>>> 'unlimited' :-)
>>>
>>
>> It's not a problem to set it to a new reasonable value in the tree, but
>> it will be a problem to fix this everywhere.
>>
>>> Also, note that currently RLIMIT_MEMLOCK is abused at least in vslock()
>> (used at
>>> least by sysctl's kernel side).  The temporary wirings performed as an
>>> implementation detail or side-effect should not be accounted against the
>> limit.
>>>  The limit is for wirings that a user makes and controls explicitly.  It
>> should
>>> not be applied to something that kernel does behind the scenes without
>> user's
>>> knowledge.
>>>
>>
>> I was surprised when I stepped on this few years ago on machine with
>> thousands processes.  top(8) ate 100% CPU in a forever loop, ps(1)
>> didn't work, and that is because memorylocked limit was set to low.
>> Later I submitted two patches which fixed kvm (r230873) and sockstat
>> (r230874), but I totally agree with you here, we shouldn't check for
>> limits in vslock().
>>
>>
> I agree with Andriy's argument for making the following change.  Please go
> ahead and commit it.
> 

Thanks, I will commit it after approving from kib.

But can we do better and don't lock process's memory in sysctl handlers?

-- 
Andrey Zonov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 535 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20120829/1d5aa5d5/signature.pgp