atom feed24 messages in org.freebsd.freebsd-gnomeSeahorse issues
FromSent OnAttachments
Coleman KaneApr 9, 2008 6:33 pm 
Joe Marcus ClarkeApr 9, 2008 9:23 pm 
Coleman KaneApr 9, 2008 9:44 pm 
Joe Marcus ClarkeApr 10, 2008 6:11 am 
Joe Marcus ClarkeApr 11, 2008 12:13 am 
Coleman KaneApr 11, 2008 1:26 pm 
Coleman KaneApr 11, 2008 2:14 pm 
Joe Marcus ClarkeApr 11, 2008 3:54 pm 
Coleman KaneApr 11, 2008 4:14 pm 
Coleman KaneApr 11, 2008 4:50 pm 
Coleman KaneApr 12, 2008 4:43 pm 
Joe Marcus ClarkeApr 12, 2008 5:00 pm 
Coleman KaneApr 12, 2008 5:14 pm 
Joe Marcus ClarkeApr 12, 2008 5:38 pm 
Jeremy MessengerApr 12, 2008 5:40 pm 
Joe Marcus ClarkeApr 12, 2008 5:49 pm 
Joe Marcus ClarkeApr 12, 2008 5:51 pm 
Jeremy MessengerApr 12, 2008 6:17 pm 
Coleman KaneApr 12, 2008 6:21 pm 
Coleman KaneApr 12, 2008 6:29 pm 
M. Warner LoshApr 12, 2008 6:37 pm 
M. Warner LoshApr 12, 2008 6:44 pm 
Coleman KaneApr 13, 2008 11:30 pm 
Joe Marcus ClarkeApr 13, 2008 11:33 pm 
Subject:Seahorse issues
From:Coleman Kane (cok@FreeBSD.org)
Date:Apr 12, 2008 6:21:51 pm
List:org.freebsd.freebsd-gnome

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

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.