From cherry@spica.trombik.org  Wed Jun  4 04:11:29 2008
Return-Path: <cherry@spica.trombik.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 972DB1065677
	for <FreeBSD-gnats-submit@freebsd.org>; Wed,  4 Jun 2008 04:11:29 +0000 (UTC)
	(envelope-from cherry@spica.trombik.org)
Received: from spica.trombik.org (spica.trombik.org [211.19.48.12])
	by mx1.freebsd.org (Postfix) with ESMTP id 612118FC13
	for <FreeBSD-gnats-submit@freebsd.org>; Wed,  4 Jun 2008 04:11:29 +0000 (UTC)
	(envelope-from cherry@spica.trombik.org)
Received: by spica.trombik.org (Postfix, from userid 999)
	id EC3C1175C3C; Wed,  4 Jun 2008 13:11:27 +0900 (JST)
Message-Id: <20080604041127.EC3C1175C3C@spica.trombik.org>
Date: Wed,  4 Jun 2008 13:11:27 +0900 (JST)
From: Tomoyuki Sakurai <cherry@trombik.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc: pauls@utdallas.edu
Subject: [PATCH] security/sguil-server: ${PREFIX}/lib/sguil-server has wrong perm, owner and group
X-Send-Pr-Version: 3.113
X-GNATS-Notify: pauls@utdallas.edu

>Number:         124257
>Category:       ports
>Synopsis:       [PATCH] security/sguil-server: ${PREFIX}/lib/sguil-server has wrong perm, owner and group
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    amdmi3
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 04 04:20:04 UTC 2008
>Closed-Date:    Mon Mar 16 01:52:21 UTC 2009
>Last-Modified:  Mon Mar 16 01:52:21 UTC 2009
>Originator:     Tomoyuki Sakurai
>Release:        FreeBSD 7.0-STABLE i386
>Organization:
>Environment:
System: FreeBSD spica.trombik.org 7.0-STABLE FreeBSD 7.0-STABLE #0: Sun May 11 18:07:51 JST 2008
>Description:
pkg-install messed up perm and owner/group of
${PREFIX}/lib/sguil-server.  "install -o sguild -g sguild -m 0750" is
not something you expect in lib directory.

Port maintainer (pauls@utdallas.edu) is cc'd.

Generated with FreeBSD Port Tools 0.77
>How-To-Repeat:
>Fix:

--- sguil-server-0.7.0_3.patch begins here ---
diff -ruN --exclude=CVS /usr/ports/security/sguil-server/Makefile /usr/home/cherry/svk/ports/security/sguil-server/Makefile
--- /usr/ports/security/sguil-server/Makefile	2008-06-01 20:48:57.000000000 +0900
+++ /usr/home/cherry/svk/ports/security/sguil-server/Makefile	2008-06-04 12:58:21.000000000 +0900
@@ -7,7 +7,7 @@
 
 PORTNAME=	sguil-server
 PORTVERSION=	0.7.0
-PORTREVISION=	2
+PORTREVISION=	3
 CATEGORIES=	security
 MASTER_SITES=	SF
 MASTER_SITE_SUBDIR=	sguil
diff -ruN --exclude=CVS /usr/ports/security/sguil-server/files/pkg-install.in /usr/home/cherry/svk/ports/security/sguil-server/files/pkg-install.in
--- /usr/ports/security/sguil-server/files/pkg-install.in	2008-06-01 20:48:57.000000000 +0900
+++ /usr/home/cherry/svk/ports/security/sguil-server/files/pkg-install.in	2008-06-04 12:55:47.000000000 +0900
@@ -77,7 +77,7 @@
 			pw usershow ${sguil_user}
 		fi
 	fi
-	for dir in %%PREFIX%%/lib/%%SGUILDIR%% /var/run/%%SGUILDIR%% ; do
+	for dir in /var/run/%%SGUILDIR%% ; do
 	if [ ! -d ${dir} ]; then
 		echo "Creating ${dir} ...."
 		install -d -o ${sguil_user} -g ${sguil_group} \
--- sguil-server-0.7.0_3.patch ends here ---

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: edwin 
State-Changed-When: Wed Jun 4 04:20:11 UTC 2008 
State-Changed-Why:  
Awaiting maintainers feedback (via the GNATS Auto Assign Tool) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=124257 

From: Edwin Groothuis <edwin@FreeBSD.org>
To: pauls@utdallas.edu
Cc: bug-followup@FreeBSD.org
Subject: Re: ports/124257: [PATCH] security/sguil-server: ${PREFIX}/lib/sguil-server has wrong perm, owner and group
Date: Wed, 4 Jun 2008 04:20:09 UT

 Maintainer of security/sguil-server,
 
 Please note that PR ports/124257 has just been submitted.
 
 If it contains a patch for an upgrade, an enhancement or a bug fix
 you agree on, reply to this email stating that you approve the patch
 and a committer will take care of it.
 
 The full text of the PR can be found at:
     http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/124257
 
 -- 
 Edwin Groothuis via the GNATS Auto Assign Tool
 edwin@FreeBSD.org
 
Date: Wed, 04 Jun 2008 23:31:36 -0500
From: Paul Schmehl <pauls@utdallas.edu>

 I don't see what the problem is.  The pkg-install script section to which 
 you refer is optional.  Furthermore, it warns you that it creates user and 
 group accounts named sguil.  The only time the directories will change 
 user and group ownership and perms is if you choose to run the script.  I 
 also fail to see how the perms used create a problem.  If you choose to 
 run sguil as root, there's no problem.  If you choose to run sguil as some 
 other user, then you *should* opt out of that portion of the script. 
 Worst case scenario you simply change the permissions to what you want 
 after you install.
 
 I looked for some guidance in hier (7) to see if there was a required 
 protocol for perms on directories but didn't find one.  Perhaps you can 
 point me to something that says the perms assigned by the script are 
 incorrect.
 
 Paul Schmehl (pauls@utdallas.edu)
 Senior Information Security Analyst
 The University of Texas at Dallas
 http://www.utdallas.edu/ir/security/

From: Tomoyuki Sakurai <cherry@trombik.org>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: ports/124257: [PATCH] security/sguil-server: ${PREFIX}/lib/sguil-server has wrong perm, owner and group
Date: Fri, 6 Jun 2008 01:54:14 +0900

 I don't have any pointer to proper permission of lib directory.
 However, I'll show you some facts.
 
 The following command shows nothing on my hosts (FreeBSD, OpenBSD and
 Gentoo/Linux). My laptop has more than 1,500 ports installed.
 
 > find /usr/local/lib -type d -perm 750
 
 The next one shows the current ports tree doesn't have any port which installs
 anything into ${PREFIX}/lib with 750. Of course, the regex isn't perfect (it
 misses ${INSTALL} in multiple lines, ports like yours which doesn't use
 ${MACRO} provided by the ports framework and various other reasons). However, 
 if you find a port which uses 0750 as permission for lib directory, let me 
 know. I'm happy to submit another PR.
 
 > ack -a '\${INSTALL}.*-m\s+\d?7\d{2}\s.*\${PREFIX}/lib[^ed]' /usr/ports/
 
 /usr/ports/databases/libudbc/Makefile
 41:     @${INSTALL} -c -o ${SHAREOWN} -g ${SHAREGRP} -m 755  
 ${WRKDIR}/udbcsdk/lib/libudbc.la ${PREFIX}/lib
 
 42:     @${INSTALL} -c -o ${LIBOWN} -g ${LIBGRP} -m 755 
 ${WRKDIR}/udbcsdk/lib/libudbc.so ${PREFIX}/lib
 
 
 /usr/ports/devel/linuxthreads/Makefile
 216:    ${INSTALL} -d -o ${BINOWN} -g ${BINGRP} -m 0755 ${PREFIX}/lib
 
 
 /usr/ports/devel/linuxthreads/files/patch-aa
 146:+   ${INSTALL} -d -o ${BINOWN} -g ${BINGRP} -m 0755 ${PREFIX}/lib
 
 
 /usr/ports/security/bsp_upektfmess/Makefile
 54:     ${INSTALL} -o root -m 0755 ${TFMESSPATH}/libtfmessbsp.so ${PREFIX}/lib
 
 NOTE: ${LIBOWN} is defined in /usr/share/mk/bsd.own.mk
 
 Thanks to 0750, findlibusers.py[1] doesn't work anymore when executed by an
 unprivileged user. You're free to say that its error handling is not robust
 enough, of courese. Also, locate(1) silently ignores any files under
 ${PREFIX}/lib/sguil-server. The user will find out that s/he is not supposed 
 to assume that system lib directory is world-readable.
 
 I'm sure it breaks other things.
 
 7[05]0 makes sense in some cases (mostly for security season), but not in this
 case. If you have a particular reason, I'd like to know.
 
 [1] http://www.maxlor.com/freebsd-scripts.shtml
 
 -- 
 Tomoyuki Sakurai
Responsible-Changed-From-To: freebsd-ports-bugs->amdmi3 
Responsible-Changed-By: amdmi3 
Responsible-Changed-When: Fri Sep 12 14:35:49 UTC 2008 
Responsible-Changed-Why:  
I'll take it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=124257 

From: Dmitry Marakasov <amdmi3@amdmi3.ru>
To: bug-followup@FreeBSD.org
Cc: Paul Schmehl <pauls@utdallas.edu>
Subject: Re: ports/124257: [PATCH] security/sguil-server:
	${PREFIX}/lib/sguil-server has wrong perm, owner and group
Date: Fri, 12 Sep 2008 18:53:39 +0400

 > Synopsis: [PATCH] security/sguil-server: ${PREFIX}/lib/sguil-server has wrong perm, owner and group
 > 
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=124257
 The questions to maintainer are:
 
 1) Is there a reason for ${PREFIX}/lib/sguil-server to be
 non-world-readable?
 2) Is there a reason for ${PREFIX}/lib/sguil-server to be
 owned by not root:wheel?
 
 If there are no real reasons for those, the directory should not
 be installed with nondefault ownerwhip/permissions.
 
 From what I see, it addition 1) breaks some utilites that may read
 /usr/local/lib and 2) may be a security issue, as software which
 is run with unpriviledged user credentials should not be able to
 alter sources of itself or its modules.
 
 The only possible reason I can see for 2) is that changing/adding/deleting
 files under ${PREFIX}/lib/sguil-server is intended behavior. If
 that is so, the directory should be located under /var in the first
 place.
 
 -- 
 Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
 amdmi3@amdmi3.ru  ..:  jabber: amdmi3@jabber.ru    http://www.amdmi3.ru

From: Paul Schmehl <pauls@utdallas.edu>
To: bug-followup@FreeBSD.org, cherry@trombik.org
Cc:  
Subject: Re: ports/124257: [PATCH] security/sguil-server:
 ${PREFIX}/lib/sguil-server has wrong perm, owner and group
Date: Thu, 12 Feb 2009 17:36:23 -0600

 --==========B79CE5E0B60D68A5025C==========
 Content-Type: text/plain; charset=us-ascii; format=flowed
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: inline
 
 I just noticed this PR.  Don't know how I lost track of it.  Anyway, to answer=20
 your questions:
 
 1) I thought I was following protocol.  I actually modeled my pkg-install=20
 script off of the one in the sguid proxy port, which sets two directories to=20
 750.
 
 There are a number of ports that use the perms 750 for various directories,=20
 particularly in pkg-install scripts.
 
 # grep -r 750 /usr/ports/* | grep -ic chmod
 46
 
 /usr/ports/comms/gnokii/pkg-install:    chmod 750 ${BINS}
 /usr/ports/databases/frontbase/pkg-install:     chmod 750=20
 ${PKG_PREFIX}/FrontBase/Backups
 /usr/ports/databases/frontbase/pkg-install:     chmod 750=20
 ${PKG_PREFIX}/FrontBase/Databases
 /usr/ports/databases/frontbase/pkg-install:     chmod 750=20
 ${PKG_PREFIX}/FrontBase/TransactionLogs
 /usr/ports/devel/flyspray/files/pkg-install.in:         %%CHMOD%% 750=20
 %%ATTACHMENTDIR%%
 /usr/ports/devel/perforce/pkg-install:          chmod 750 $PERFORCE_ROOT
 /usr/ports/games/mangband/Makefile:     ${CHMOD} 750 ${MALIB}/*
 /usr/ports/irc/bopm/Makefile:   @${CHMOD} 750 ${LOGDIR}
 /usr/ports/irc/inspircd/files/pkg-install.in:   chmod 750 $etcdir
 /usr/ports/irc/ircd-ratbox/files/pkg-install.in:&& chmod 750 %%LOGDIR%%
 /usr/ports/irc/ircd-ratbox/files/pkg-install.in:&& chmod 750 %%RUNDIR%%
 /usr/ports/irc/ircd-ratbox/files/pkg-install.in:        chmod 750=20
 ${PKG_PREFIX}/etc/ircd-ratbox/
 /usr/ports/irc/ircd-ratbox-devel/files/pkg-install.in:&& chmod 750 %%LOGDIR%%
 /usr/ports/irc/ircd-ratbox-devel/files/pkg-install.in:&& chmod 750 %%RUNDIR%%
 /usr/ports/irc/ircd-ratbox-devel/files/pkg-install.in:&& chmod 750 %%DBDIR%%
 /usr/ports/irc/ircd-ratbox-devel/files/pkg-install.in:  chmod 750=20
 %%PREFIX%%/etc/ircd-ratbox/
 /usr/ports/irc/ratbox-services/files/pkg-install.in:&& chmod 750 %%DBDIR%%
 
 If that's incorrect, a lot more than this one need to be fixed.  Having said=20
 that, I really don't care one way or the other, but I do think I need guidance, =
 
 and some standard needs to be followed.
 
 2) My answer for this is the same.  I modeled the script after the squid=20
 pkg-install script, which makes the user:group of the process owner of the=20
 files.  If this is incorrect behavior, I need to know that.
 
 No, the sguild user does not need to alter any of the files in=20
 ${PREFIX}/lib/sguil-server.
 
 If I need to change these things, I need to know pretty soon, because I'm=20
 working on a patch for the pkg-install script to fix a problem with package=20
 building.
 
 Sorry I didn't reply to you sooner.
 
 --=20
 Paul Schmehl (pauls@utdallas.edu)
 Senior Information Security Analyst
 The University of Texas at Dallas
 http://www.utdallas.edu/ir/security/
 
 --==========B79CE5E0B60D68A5025C==========
 Content-Type: application/pkcs7-signature
 Content-Transfer-Encoding: base64
 
 MIIO6gYJKoZIhvcNAQcCoIIO2zCCDtcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3
 DQEHAaCCDFgwggVxMIIE2qADAgECAhAjTUKxM7GPfyq3eKDLB928MA0GCSqGSIb3
 DQEBBQUAMIHqMScwJQYDVQQKEx5UaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBTeXN0
 ZW0xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl
 cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTk5
 MTIwMAYDVQQLEylDbGFzcyAyIENBIC0gT25TaXRlIEluZGl2aWR1YWwgU3Vic2Ny
 aWJlcjEtMCsGA1UEAxMkVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgYXQgRGFsbGFz
 IENBMB4XDTA4MTAwOTAwMDAwMFoXDTA5MTAwOTIzNTk1OVowgfYxJzAlBgNVBAoU
 HlRoZSBVbml2ZXJzaXR5IG9mIFRleGFzIFN5c3RlbTEtMCsGA1UECxQkVGhlIFVu
 aXZlcnNpdHkgb2YgVGV4YXMgYXQgRGFsbGFzIENBMUYwRAYDVQQLEz13d3cudmVy
 aXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4gYnkgUmVmLixMSUFCLkxU
 RChjKTk5MRgwFgYDVQQLFA9NYWlsIFN0b3AgLSBVVEQxFzAVBgNVBAMTDlBhdWwg
 TCBTY2htZWhsMSEwHwYJKoZIhvcNAQkBFhJwYXVsc0B1dGRhbGxhcy5lZHUwgZ8w
 DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJgefOcDbxwKqkF+wQR3yQWoiOyiA0yU
 DDaVDIENfyOjM2eo8WTarpHqHK8SM3v3DU2MiOwyeqiiy9HmH7k1o5NXkvCxNZzI
 ju4RgLqH2FGfSwPqHngQ5GN7cIiXxY+yQGmvjaTo++6H31M9T8MNwJ9rQVktUdyI
 d/iTBspoPf71AgMBAAGjggIIMIICBDAJBgNVHRMEAjAAMB0GA1UdEQQWMBSBEnBh
 dWxzQHV0ZGFsbGFzLmVkdTCCASQGA1UdIASCARswggEXMIIBEwYLYIZIAYb4RQEH
 AQYwggECMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh
 LWtyMIHSBggrBgEFBQcCAjCBxRqBwk5PVElDRTogUHJpdmF0ZSBrZXkgbWF5IGJl
 IHJlY292ZXJlZCBieSBWZXJpU2lnbidzIGN1c3RvbWVyIHdobyBtYXkgYmUgYWJs
 ZSB0byBkZWNyeXB0IG1lc3NhZ2VzIHlvdSBzZW5kIHRvIGNlcnRpZmljYXRlIGhv
 bGRlci4gIFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZl
 cmlzaWduLmNvbS9ycGEta3IgKGMpOTkuMBEGCWCGSAGG+EIBAQQEAwIHgDBxBgNV
 HR8EajBoMGagZKBihmBodHRwOi8vb25zaXRlY3JsLnZlcmlzaWduLmNvbS9UaGVV
 bml2ZXJzaXR5b2ZUZXhhc1N5c3RlbVRoZVVuaXZlcnNpdHlvZlRleGFzYXREYWxs
 YXNDQS9MYXRlc3RDUkwwCwYDVR0PBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwME
 BggrBgEFBQcDAjANBgkqhkiG9w0BAQUFAAOBgQAJmIztXAsnxxZwKhhgSy7VM+kM
 ijplZzLOLvtWByziCmE6CRGxhLPClws72qICwfcg6rkAiBOUc49oto+Q2K22Rj2U
 LrVbAtbtGA8PS4WX0D6focxS3W8VAlUzohAQQfbxSJrV09DbVyjKCCwRC0x4/Xqr
 WtjRctBI3YxIEIxrPDCCA9gwggNBoAMCAQICEEHsHz2nFAeWxPbVDN3RD2UwDQYJ
 KoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg
 SW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0
 aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2lnbiwg
 SW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2ln
 biBUcnVzdCBOZXR3b3JrMB4XDTk5MDMzMTAwMDAwMFoXDTA5MDMzMDIzNTk1OVow
 geoxJzAlBgNVBAoTHlRoZSBVbml2ZXJzaXR5IG9mIFRleGFzIFN5c3RlbTEfMB0G
 A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2Yg
 dXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpOTkxMjAwBgNV
 BAsTKUNsYXNzIDIgQ0EgLSBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyMS0w
 KwYDVQQDEyRUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBhdCBEYWxsYXMgQ0EwgZ8w
 DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL/q74frHgrBAPkiEcHRwczbetq+NtJw
 YDBg5RngUy819MmoKQXW3j2d8waaZH2+0YdUeJv/onjx+4erw/yHTMJJQQ3hwNKl
 1/x+/0JRTnTzAdVoc6VdBDH45iklY6gjmkRqgYsPsDnx79tGWMO6uM9L83rBokmV
 gyNDupsajzKFAgMBAAGjgaUwgaIwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVBy
 aXZhdGVMYWJlbDEtMTQwMBEGCWCGSAGG+EIBAQQEAwIBBjBEBgNVHSAEPTA7MDkG
 C2CGSAGG+EUBBwEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWdu
 LmNvbS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN
 AQEFBQADgYEAUwm13LK2idEgUIPJOHncyAiySb+4U4Nvisyy5Hp8/KPoD19hXl+X
 BJUSWtKVASLxvO3xVLZUplQYoZ1UvAZpBMcCITeigjmIp6ygn+iDGV2SSDkaWYIk
 IEO8hpUS3IN04ebjE75qpIcAMTEjByWbr7osUZEOWaajF4jStM5UFxwwggMDMIIC
 bAIRALkvYMyIn6F6Rgm4W3Bsiq8wDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT
 AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQ
 dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYD
 VQQLEzEoYykgMTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVz
 ZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMB4XDTk4MDUx
 ODAwMDAwMFoXDTI4MDgwMTIzNTk1OVowgcExCzAJBgNVBAYTAlVTMRcwFQYDVQQK
 Ew5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFy
 eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5
 OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYD
 VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMIGfMA0GCSqGSIb3DQEBAQUAA4GN
 ADCBiQKBgQCniAEhdCznGgPwmOGXPA8hCPGc25fpmvzCBAYTvl9SyMweLBJWLLgB
 aSzMmR+tsJaueQTyEznBe5i6CCzowoQTLKpp6Qn0x6kCpELCI09K2PAOovsxbMnm
 b5knB/Xm9Ex4nm3rRob6uYbJVPKyxK/URhxayRUw/w1s9S0Obc5/dwIDAQABMA0G
 CSqGSIb3DQEBBQUAA4GBAHIu+X/R8XH7xJ72xV5RikCYuGj4mxyD2OKdvf/toeZm
 6i8J9MrX6qUrlfYkYIZNRC6DpcQtoNOueGlvctpsrgjwY5I35rvEMBetd8xJNarP
 2I/RvrcYlkdzalQiNGQtthabWVu0UVk6swsU9BLfZ6D0rTJkXrFGcieMEnvFRLSu
 MYICWjCCAlYCAQEwgf8wgeoxJzAlBgNVBAoTHlRoZSBVbml2ZXJzaXR5IG9mIFRl
 eGFzIFN5c3RlbTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
 A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
 cGEgKGMpOTkxMjAwBgNVBAsTKUNsYXNzIDIgQ0EgLSBPblNpdGUgSW5kaXZpZHVh
 bCBTdWJzY3JpYmVyMS0wKwYDVQQDEyRUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBh
 dCBEYWxsYXMgQ0ECECNNQrEzsY9/Krd4oMsH3bwwCQYFKw4DAhoFAKCBsTAYBgkq
 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAyMTIyMzM2
 MjNaMCMGCSqGSIb3DQEJBDEWBBSMmcZF/iwU678MeViN2lER5tgewjBSBgkqhkiG
 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
 AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgHLs
 Si/g4U7H0Ke8Bhqg5WiOLeeJK6/kzIozYAMFofX8Hm+6HIsAdwq4zTyfyXNfLKBD
 2bTP07DdpmU3wsacrxWumg38y2VbSuBURQAum5eK8HQ8ZszIrfBYhMCkWxTZHqTa
 s9qb89EYprUAfzQBx2ak1I5sZjUbwc5JVMPDbkzF
 
 --==========B79CE5E0B60D68A5025C==========--
 
State-Changed-From-To: feedback->closed 
State-Changed-By: amdmi3 
State-Changed-When: Mon Mar 16 01:46:26 UTC 2009 
State-Changed-Why:  
Userland utilities that can't handle inaccessible directories during 
hierarchy traversing are not enough reason to just dump explicitly set 
restrictive permissions for a security tool. Custom scripts not for 
public eye may be placed into directory in question so there's reason 
for it to be non-world-readable. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=124257 
>Unformatted:
