Date: Wed, 29 Aug 2012 12:34:59 +0400 From: Andrey Zonov <zont@FreeBSD.org> To: alc@freebsd.org Cc: Bryan Drewery <bryan@shatow.net>, Alan Cox <alan.l.cox@gmail.com>, Andriy Gapon <avg@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: [patch] unprivileged mlock(2) Message-ID: <503DD433.2030108@FreeBSD.org> In-Reply-To: <CAJUyCcMjUSUSyF9Ry3d16izrYCjebQFtpYy0OiFof%2BgOKAs5Qg@mail.gmail.com> References: <503CF3B1.3050604@FreeBSD.org> <503D08D6.1040004@shatow.net> <503D281A.3080107@FreeBSD.org> <503D34DB.3090000@FreeBSD.org> <CAJUyCcMjUSUSyF9Ry3d16izrYCjebQFtpYy0OiFof%2BgOKAs5Qg@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 8/29/12 8:39 AM, Alan Cox wrote: > On Tue, Aug 28, 2012 at 4:15 PM, Andrey Zonov <zont@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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQPdQzAAoJEBWLemxX/CvTvJoIAI/rRlQIW7hjQYN2Bqt8lD2L ohIi67fCq8lsyGkbqBleFJCGTRpjSGKpQMT6ZD1cTjHi8WkzmJQMRO2sn7m2dBcI uCYs/LNHVf4xnNukeANGJ838jdjWPIrlEfnrh3CiPB8/BCUu05X7vKh1c6np9E7+ hcD8pJGl568Jg3Z2l+SBenbv7c6acWd4tBu2xHtnnz5x2Ly7nSZjbJ553ZbQKXlQ THH2w2GuRc4B1JYhhGWuU5n7t5W4UOWMzQUZnG4YayUTEowcqz6+4vcuEsqEJ2zd 4jwqm7G5eXxaHJ7yCPs6MPrd9JRMKYaGB2SBzAzFo95bdLkuyQCAhNoEGlsybvE= =GQxu -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?503DD433.2030108>