Date: Sat, 12 Apr 2008 12:43:26 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: cokane@FreeBSD.ORG Cc: gnome@FreeBSD.ORG Subject: Re: Seahorse issues Message-ID: <20080412.124326.154576604.imp@bsdimp.com> In-Reply-To: <1208024491.1327.5.camel@localhost> References: <1208021918.82222.18.camel@shumai.marcuscom.com> <1208022694.82222.25.camel@shumai.marcuscom.com> <1208024491.1327.5.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <1208024491.1327.5.camel@localhost>
Coleman Kane <cokane@freebsd.org> writes:
: On Sat, 2008-04-12 at 13:51 -0400, Joe Marcus Clarke wrote:
: > On Sat, 2008-04-12 at 13:38 -0400, Joe Marcus Clarke wrote:
: > > On Sat, 2008-04-12 at 12:43 -0400, Coleman Kane wrote:
: > > >
: > > > As for the mlock() privilege issue, I am not sure what we'll do about
: > > > that. It would be nice, at some point, to support that feature for
: > > > normal users. As long as I'm diligent about my swap-space, etc... and
: > > > access to my workstation, I'm *pretty* secure. Things like common-use
: > > > lab computers, etc... are probably more appropriate for this feature.
: > >
: > > Since we already have an rlimit for locked memory (RLIMIT_MEMLOCK), and
: > > it is used by the mlock(2) syscall, what about the attached patch to add
: > > a sysctl to control user access to mlock (but not allowing mlockall(2))?
: > > This has been tested to fix the gnome-keyring issue when the sysctl is
: > > set to 1. If this is agreeable, I can add some manpage docs as well.
: >
: > Minor modification to allow munlock(2) as well as mlock(2).
: >
: > http://www.marcuscom.com/downloads/vm_mmap.c.diff
: >
: > Joe
: >
:
: I've reviewed these patches, and also read up on the Linux 2.6.9+
: implementation, as well as referred to various documentations about it.
: I'd like to float an email to current@ and see what comes up there
: regarding unprivileged mlock(2). There might already be a "more proper"
: approach that just isn't being employed.
:
: The one thing that worries me is whether or not this could be used by a
: local user to bring about a DoS on a machine. I *think* that, if you set
: the hard limit during startup, then enforce a good soft-limit, then
: you'll be pretty safe.
:
: Anyhow, I'll see what sort of comments I can get.
At the very least we'd have to change the defaults:
memorylocked infinity kB
I'm not sure where else this rlimit is used, so some careful study may
be needed. Before people are going to be comfortable allowing this
in, you'll need to say that this limit is used for A B C now and
mlock() usage is similar to it in this way or that way and what the
potential for local DoS is with any change...
I'm also not sure I like the sysctl part, but I'll defer to others on
that...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080412.124326.154576604.imp>