Date: Sat, 12 Apr 2008 14:28:54 -0400 From: Coleman Kane <cokane@FreeBSD.org> To: Jeremy Messenger <mezz7@cox.net> Cc: gnome@freebsd.org Subject: Re: Seahorse issues Message-ID: <1208024934.1327.9.camel@localhost> In-Reply-To: <op.t9ifvbe79aq2h7@mezz.mezzweb.com> References: <47FD09AC.2020907@FreeBSD.org> <1207776230.61729.28.camel@shumai.marcuscom.com> <47FD34E8.2000005@FreeBSD.org> <1207807915.61729.40.camel@shumai.marcuscom.com> <op.t9id5keu9aq2h7@mezz.mezzweb.com> <1208022563.82222.22.camel@shumai.marcuscom.com> <op.t9ifvbe79aq2h7@mezz.mezzweb.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2008-04-12 at 13:19 -0500, Jeremy Messenger wrote: > On Sat, 12 Apr 2008 12:49:23 -0500, Joe Marcus Clarke > <marcus@marcuscom.com> wrote: > > > On Sat, 2008-04-12 at 12:42 -0500, Jeremy Messenger wrote: > >> On Thu, 10 Apr 2008 01:11:55 -0500, Joe Marcus Clarke > >> <marcus@marcuscom.com> wrote: > >> > >> <snip> > >> > The problem is the fact that FreeBSD's mlock() requires setuid > >> > privileges, and thus seahorse cannot allocate secure memory. The > >> > >> Yesterday, I have found archives about mlock() in freebsd-arch@. > >> > >> http://lists.freebsd.org/pipermail/freebsd-arch/2006-July/005496.html > > > > Yes, this thread talks about the problem exactly. The patch I just sent > > out attempts to address this concern using a user-settable sysctl. > > Peter is suggesting this be handled automatically by setting a > > reasonable default limit on RLIMIT_MEMLOCK. > > Yeah and even rwatson liked his suggest. I like automatically better, but > tweak in sysctl is fine with me too. Some hardcore probably prefer sysctl > than automatically one. > > >> It leads to: > >> > >> http://people.freebsd.org/~kib/overcommit/index.html > >> > >> I am not sure if it's useful for this issue. > > > > This doesn't look like it will help this issue. This is dealing with > > overcommitting swap. > > It's what I though so. > > Cheers, > Mezz > > > Joe > If we could turn this into a per-user, system-wide value, I think that would be the best approach. However, this probably ends up violating the canonical meaning of RLIMIT_MEMLOCK (if there is even a standard set-in-stone meaning for it). I am curious if we could use something like the MAC facility to provide a method for preventing mlock() access to some non-root users, while providing it to others. -- Coleman Kane
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1208024934.1327.9.camel>