cokane at FreeBSD.org
Sat Apr 12 18:29:27 UTC 2008
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 at 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 at 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 at .
> >> 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.
> > 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.
More information about the freebsd-gnome