From owner-freebsd-standards@FreeBSD.ORG Tue Jul 20 19:21:24 2010 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92AD61065670 for ; Tue, 20 Jul 2010 19:21:23 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 428598FC1E for ; Tue, 20 Jul 2010 19:21:22 +0000 (UTC) Received: by ywf9 with SMTP id 9so712793ywf.13 for ; Tue, 20 Jul 2010 12:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=Znz5PbIcMxtavTP66fAN9ujQ9hl9fUD5IxBQ6I4LfkY=; b=YDUClfmIpUB2+6cd0qO+qyHzU6Q8o4kZ8GDiIN0H6s9hqM8UJeKFyOQ53NYhRAH4Te aU8OE6hgoNXc7ynMwL7RwY0J30M9/pOB+UTTyjgiIBvjs6m+9+sSrbuvjyLJWaT+wyQM AKdxb7K/viocdqGlVcjMa80jO8NPmmp/E8N3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=UWJHe8vVAwZEP1+EQ5+mwwthF8OEx3+wvzzKequiAg3g2kbFpts5DhuP9Kb9zpvvYp fhL4EA6SKmDrsafPUNwJZNmkQGgHqXbJJNjGVzBAoNyCLdzX5t/RHDPtOVFV27cDUtXh /HlMUbVfVXzbkdAfP/hrM79/EXyuTzFM6paSU= MIME-Version: 1.0 Received: by 10.100.124.1 with SMTP id w1mr1040764anc.265.1279652122708; Tue, 20 Jul 2010 11:55:22 -0700 (PDT) Received: by 10.231.169.18 with HTTP; Tue, 20 Jul 2010 11:55:22 -0700 (PDT) Date: Tue, 20 Jul 2010 11:55:22 -0700 Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: standards@freebsd.org Subject: Chasing down bugs with access(2) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:21:24 -0000 Hi Hackers, I ran into an issue last night where apparently several apps make faulty assumptions w.r.t. whether or not access(2) returns functional data when running as a superuser. POSIX says: In early proposals, some inadequacies in the access() function led to the creation of an eaccess() function because: 1. Historical implementations of access() do not test file access correctly when the process' real user ID is superuser. In particular, they always return zero when testing execute permissions without regard to whether the file is executable. 2. The superuser has complete access to all files on a system. As a consequence, programs started by the superuser and switched to the effective user ID with lesser privileges cannot use access() to test their file access permissions. However, the historical model of eaccess() does not resolve problem (1), so this volume of IEEE Std 1003.1-2001 now allows access() to behave in the desired way because several implementations have corrected the problem. It was also argued that problem (2) is more easily solved by using open(), chdir(), or one of the exec functions as appropriate and responding to the error, rather than creating a new function that would not be as reliable. Therefore, eaccess() is not included in this volume of IEEE Std 1003.1-2001. The sentence concerning appropriate privileges and execute permission bits reflects the two possibilities implemented by historical implementations when checking superuser access for X_OK. New implementations are discouraged from returning X_OK unless at least one execution permission bit is set. FreeBSD says: Even if a process's real or effective user has appropriate privileges and indicates success for X_OK, the file may not actually have execute per- mission bits set. Likewise for R_OK and W_OK. This results in: sh/test - ok-ish (a guy on bash-bugs challenged the fact that the syscall was buggy based on the details returned). bash - broken (builtin test(1) always returns true) csh - not really ok (uses whacky stat-like detection; doesn't check for ACLs, or MAC info) perl - ok (uses eaccess(2) for our OS). python - broken (uses straight access(2), so os.access is broken). So now the question is how to fix this? Linux reports the correct mode for the file (when operating as superuser or not), and there's a lot of code outside of *BSD that builds upon that assumption because stat(2) doesn't test for permissions via POSIX ACLs, MAC, etc. I tried munging through the code to determine where VOP_ACCESS was coming from but I got lost. Where should I look for this? Thanks, -Garrett