====== mlock(2) on FreeBSD ======

On FreeBSD, the **mlock(2)** call is privileged-only, meaning that you must be the superuser to run it. Under Linux (//since 2.6.9//), this restriction has been lifted, allowing **mlock(2)** to be available for any normal user. The benefit to this is that user-level keying and encryption systems may be employed which make use of this, further protecting the users' data from potential system thieves.

One application which uses this mechanism is [[http://www.freshports.org/security/gnome-keyring/|gnome-keyring]]. The [[http://www.freshports.org/security/seahorse|Seahorse]] software provides a number of helpful tools to make use of the keyring with user applications such as Evolution, SSH, GnuPG, and others. Unfortunately, the current Seahorse port assumes that **mlock(2)** is functioning properly, and proceeds to crash when it unexpectedly gets a NULL pointer from a failed secure-malloc attempt by **libgnome-keyring**. 

The following patch fixes this crash by allowing Seahorse applications to detect, at startup, if secure memory is available. If not, they'll print a short warning to the user, and then proceed on to operate with normal unsecured system malloc.
  * Patch for seahorse port: {{freebsd:security_seahorse-no-mlock.patch}}

To apply the patch (download it, then follow these shell instructions):
<code bash>cd /usr/ports
patch -p0 < ~/security_seahorse-no-mlock.patch</code>

This led into some further discussion about how to possibly improve the **mlock(2)** implementation, so as to provide the handy feature to unprivileged users.


===== Add a Sysctl to Allow Unprivileged Use =====

Joe Marcus Clarke has posted a patch to ''src/sys/vm/vm_mmap.c'' that allows a sysctl to be modified which turns off the privilege checks. The patch is available here (//I've since corrected it//):
  * {{freebsd:vm_mmap.c.diff}}

One problem with this implementation is that it may open up a vector allowing an unprivileged user to ''mlock(2)'' (''RLIMIT_NPROC'' * ''RLIMIT_MEMLOCK'') bytes of memory, potentially stealing away precious system RAM until the system becomes unusable. However, for a personal system that is wanting to ensure that //precious datas// don't get swapped to disk, this may be a good option.