From owner-freebsd-ports@FreeBSD.ORG Mon Feb 7 07:53:01 2011 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 441FB10656B2 for ; Mon, 7 Feb 2011 07:53:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id C9B088FC16 for ; Mon, 7 Feb 2011 07:53:00 +0000 (UTC) Received: (qmail 27104 invoked by uid 399); 7 Feb 2011 07:52:59 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 7 Feb 2011 07:52:59 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D4FA4DA.608@FreeBSD.org> Date: Sun, 06 Feb 2011 23:52:58 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: flz@FreeBSD.org, freebsd-ports@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: pkg_info -g not working for unprivileged user + unreadable files X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 07:53:01 -0000 flz, In r206043 you converted fexists() in src/lib/libpkg/file.c to use open() instead of lstat(). Unfortunately this has the side effect of breaking 'pkg_info -g' for unprivileged users with files that have no +r bits. For example: pkg_info -g sudo-1.7.4.6 Information for sudo-1.7.4.6: Mismatched Checksums: pkg_info: /usr/local/bin/sudo doesn't exist pkg_info: /usr/local/bin/sudoedit doesn't exist pkg_info: /usr/local/bin/sudoreplay doesn't exist pkg_info: /usr/local/sbin/visudo doesn't exist Reverting your change produces the expected behavior. So my questions are, why was the change made, what are its benefits, and how can we fix this problem? :) Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/