From nobody@FreeBSD.org  Sat Aug 17 13:00:57 2013
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
	(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hub.freebsd.org (Postfix) with ESMTP id 1FB1B11D
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 17 Aug 2013 13:00:57 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.freebsd.org (Postfix) with ESMTPS id E8EE52747
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 17 Aug 2013 13:00:56 +0000 (UTC)
Received: from oldred.freebsd.org ([127.0.1.6])
	by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id r7HD0u3x091937
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 17 Aug 2013 13:00:56 GMT
	(envelope-from nobody@oldred.freebsd.org)
Received: (from nobody@localhost)
	by oldred.freebsd.org (8.14.5/8.14.5/Submit) id r7HD0uhK091909;
	Sat, 17 Aug 2013 13:00:56 GMT
	(envelope-from nobody)
Message-Id: <201308171300.r7HD0uhK091909@oldred.freebsd.org>
Date: Sat, 17 Aug 2013 13:00:56 GMT
From: Edward Tomasz Napierala <trasz@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: setproctitle(3) doesn't work with Capsicum
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         181352
>Category:       kern
>Synopsis:       [libc] setproctitle(3) doesn't work with Capsicum
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Aug 17 13:10:00 UTC 2013
>Closed-Date:    
>Last-Modified:  Sat Aug 17 18:19:56 UTC 2013
>Originator:     Edward Tomasz Napierala
>Release:        
>Organization:
FreeBSD Project
>Environment:
>Description:
setproctitle(3) doesn't work (does nothing) after entering Capsicum
capability mode.  I think this is because it depends on sysctl(2).
Still, would be nice to either provide a workaround, or at least document
this limitation.

>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:
