From owner-freebsd-standards@FreeBSD.ORG Mon Jul 19 05:20:09 2010 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DE8B1065673 for ; Mon, 19 Jul 2010 05:20:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 006CE8FC17 for ; Mon, 19 Jul 2010 05:20:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6J5K8CC095965 for ; Mon, 19 Jul 2010 05:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6J5K8vw095964; Mon, 19 Jul 2010 05:20:08 GMT (envelope-from gnats) Resent-Date: Mon, 19 Jul 2010 05:20:08 GMT Resent-Message-Id: <201007190520.o6J5K8vw095964@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-standards@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Tatsuya Hagino Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6772106567E for ; Mon, 19 Jul 2010 05:14:01 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id B59038FC0A for ; Mon, 19 Jul 2010 05:14:01 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o6J5E1Au008016 for ; Mon, 19 Jul 2010 05:14:01 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id o6J5E1JK008015; Mon, 19 Jul 2010 05:14:01 GMT (envelope-from nobody) Message-Id: <201007190514.o6J5E1JK008015@www.freebsd.org> Date: Mon, 19 Jul 2010 05:14:01 GMT From: Tatsuya Hagino To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: standards/148748: ATA Raid Metadata Read Write Inconsistency 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: Mon, 19 Jul 2010 05:20:09 -0000 >Number: 148748 >Category: standards >Synopsis: ATA Raid Metadata Read Write Inconsistency >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jul 19 05:20:08 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Tatsuya Hagino >Release: 8.1-PRERELEASE >Organization: Keio University >Environment: FreeBSD hagino2 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0: Sun Jul 18 23:53:05 JST 2010 root@:/usr/src/sys/amd64/compile/GENERIC amd64 >Description: I have reported this problem before, but it has not yet fixed. This is just a simple mistake in the source code. When using ATI (now AMD) SB700 SATA Controler and using atacontrol to create RAID1 mirroring, the metadata written on the disk by atacontrol command is VIA metadata format (since ATA metadata format in unknown), but when the metadata is read, it is read as SILICON_IMAGE metadata and it fails because it is VIA metadata format. >How-To-Repeat: 1. Use ATI SB700 SATA Controler AHCI mode 2. use atacontrol command to create RAID1 3. it fails to read the metadata created by 2 >Fix: Change /usr/src/sys/dev/ata/ata-raid.c to use the same metadata format bor both read an write. For example, I have changed ata_raid_read_metadata so that ATA_ATI_ID is not with ATA_SILICON_IMAGE_ID but with ATA_VIA_ID. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-standards@FreeBSD.ORG Mon Jul 19 11:07:06 2010 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CE5B1065679 for ; Mon, 19 Jul 2010 11:07:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE338FC17 for ; Mon, 19 Jul 2010 11:07:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6JB76rL065845 for ; Mon, 19 Jul 2010 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6JB75DS065843 for freebsd-standards@FreeBSD.org; Mon, 19 Jul 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Jul 2010 11:07:05 GMT Message-Id: <201007191107.o6JB75DS065843@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org 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: Mon, 19 Jul 2010 11:07:06 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/148748 standards ATA Raid Metadata Read Write Inconsistency o stand/147210 standards xmmintrin.h and cstdlib conflicts with each other with p stand/145517 standards POSIX getline() missing o stand/145082 standards Patch against w(1) & uptime(1) to use 24H time by defa o stand/144231 standards bind/connect/sendto too strict about sockaddr length o stand/143358 standards [libm] nearbyint(3) raises spurious inexact exception o stand/142803 standards j0 Bessel function inaccurate near zeros of the functi s stand/141705 standards [libc] [request] libc lacks cexp (and friends) o stand/130067 standards Wrong numeric limits in system headers? o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards [patch] cd9660 unicode support simple hack o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads p stand/41576 standards ln(1): replacing old dir-symlinks o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h s stand/24590 standards timezone function not compatible witn Single Unix Spec o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 44 problems total. From owner-freebsd-standards@FreeBSD.ORG Tue Jul 20 12:24:58 2010 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D5D01065816; Tue, 20 Jul 2010 12:24:58 +0000 (UTC) (envelope-from jilles@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 55D338FC24; Tue, 20 Jul 2010 12:24:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6KCOwx8030032; Tue, 20 Jul 2010 12:24:58 GMT (envelope-from jilles@freefall.freebsd.org) Received: (from jilles@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6KCOwkB030028; Tue, 20 Jul 2010 12:24:58 GMT (envelope-from jilles) Date: Tue, 20 Jul 2010 12:24:58 GMT Message-Id: <201007201224.o6KCOwkB030028@freefall.freebsd.org> To: jilles@FreeBSD.org, freebsd-standards@FreeBSD.org, freebsd-bugs@FreeBSD.org From: jilles@FreeBSD.org Cc: Subject: Re: kern/148748: [ataraid] Metadata Read Write Inconsistency 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 12:24:58 -0000 Old Synopsis: ATA Raid Metadata Read Write Inconsistency New Synopsis: [ataraid] Metadata Read Write Inconsistency Responsible-Changed-From-To: freebsd-standards->freebsd-bugs Responsible-Changed-By: jilles Responsible-Changed-When: Tue Jul 20 12:24:14 UTC 2010 Responsible-Changed-Why: Fix category/assignment. http://www.freebsd.org/cgi/query-pr.cgi?pr=148748 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 From owner-freebsd-standards@FreeBSD.ORG Wed Jul 21 07:40:08 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 901651065676; Wed, 21 Jul 2010 07:40:08 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id 4B86F8FC16; Wed, 21 Jul 2010 07:40:08 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id F08AF2167AD; Wed, 21 Jul 2010 10:22:25 +0300 (EEST) Date: Wed, 21 Jul 2010 10:22:25 +0300 From: Jaakko Heinonen To: Garrett Cooper Message-ID: <20100721072225.GA1102@a91-153-117-195.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: standards@freebsd.org, hackers@freebsd.org Subject: Re: 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: Wed, 21 Jul 2010 07:40:08 -0000 Hi, On 2010-07-20, Garrett Cooper wrote: > 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. > New implementations are discouraged from returning X_OK unless at > least one execution permission bit is set. See PR kern/125009 (http://www.freebsd.org/cgi/query-pr.cgi?pr=125009). Here is the latest version of the vaccess*() patch which also changes vaccess_acl_nfs4(): http://people.freebsd.org/~jh/patches/vaccess-VEXEC.diff The patch is not a complete fix however. Not all file systems use vaccess*() for VEXEC in their VOP_ACCESS() (ZFS confirmed). Thus the patch doesn't work with ZFS. -- Jaakko From owner-freebsd-standards@FreeBSD.ORG Wed Jul 21 09:03:05 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 B5999106564A; Wed, 21 Jul 2010 09:03:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 365758FC18; Wed, 21 Jul 2010 09:03:04 +0000 (UTC) Received: from c122-106-145-25.carlnfd1.nsw.optusnet.com.au (c122-106-145-25.carlnfd1.nsw.optusnet.com.au [122.106.145.25]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6L930EU007859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 19:03:01 +1000 Date: Wed, 21 Jul 2010 19:03:00 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jaakko Heinonen In-Reply-To: <20100721072225.GA1102@a91-153-117-195.elisa-laajakaista.fi> Message-ID: <20100721185227.N7492@delplex.bde.org> References: <20100721072225.GA1102@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Cooper , standards@freebsd.org, hackers@freebsd.org Subject: Re: 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: Wed, 21 Jul 2010 09:03:05 -0000 On Wed, 21 Jul 2010, Jaakko Heinonen wrote: > On 2010-07-20, Garrett Cooper wrote: >> 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. > >> New implementations are discouraged from returning X_OK unless at >> least one execution permission bit is set. > > See PR kern/125009 (http://www.freebsd.org/cgi/query-pr.cgi?pr=125009). > > Here is the latest version of the vaccess*() patch which also changes > vaccess_acl_nfs4(): > > http://people.freebsd.org/~jh/patches/vaccess-VEXEC.diff > > The patch is not a complete fix however. Not all file systems use > vaccess*() for VEXEC in their VOP_ACCESS() (ZFS confirmed). Thus the > patch doesn't work with ZFS. I looked at the patches in the PR. It seems reasonable to require an X but for VEXEC for all file types except directories, like I think the vaccess() version of your patch does. Keeping the existing behaviour for directories seems necessary. E.g., suppose a user changes all his files and directories to mode 000. It should still be possible for root to search, not to mention back up, all those files and directories, without clobbering any of their metadata (including atimes, but those are a different problem). Bruce From owner-freebsd-standards@FreeBSD.ORG Wed Jul 21 10:34:41 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 ED3BA1065676; Wed, 21 Jul 2010 10:34:41 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A4E7E8FC12; Wed, 21 Jul 2010 10:34:41 +0000 (UTC) Received: by iwn35 with SMTP id 35so8465736iwn.13 for ; Wed, 21 Jul 2010 03:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iiGO5+L2mjGmUIsd0GgnQK44tBX79u0TgzmdJXPe0TI=; b=UKsLGO2Axf3NJtnKaNmKygJFMbn5+VMfjMD3Lvo6DHElQbdNaBhCw+zW5s+E4szi7M 5/3eSZJ2p1z3LiZlkAvp27n6dyAF9zLJ8XNTQplkfd3G0mwN71X1W0XKC6ru2F5/4JkS QTmqHVBaZdWxHcfAcUrTy87AlBNz1UVg7C9QI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dcScXkXK9byPpyGDeXkrMirq/vtYXKjzm5bLqlkieNgPNOLNKtEB1R6KGgwODvc1Be W9dGA42iHgCoHEB4rzEwCz5Nt8RoC/EXalagndc6YWKXlTLXS3j3edsutzhdBSqtJfoT I38SXQQB/fQ3788QRG0b5I0M6+MTpCfVR8u3o= MIME-Version: 1.0 Received: by 10.231.14.194 with SMTP id h2mr8986308iba.67.1279708480674; Wed, 21 Jul 2010 03:34:40 -0700 (PDT) Received: by 10.231.169.18 with HTTP; Wed, 21 Jul 2010 03:34:40 -0700 (PDT) In-Reply-To: <20100721162044.N7348@delplex.bde.org> References: <20100721162044.N7348@delplex.bde.org> Date: Wed, 21 Jul 2010 03:34:40 -0700 Message-ID: From: Garrett Cooper To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: standards@freebsd.org, hackers@freebsd.org Subject: Re: 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: Wed, 21 Jul 2010 10:34:42 -0000 On Wed, Jul 21, 2010 at 1:40 AM, Bruce Evans wrote: > On Tue, 20 Jul 2010, Garrett Cooper wrote: ... > This seems wrong for directories. =A0It should say "... unless the file > is 'executable'". =A0'executable' means searchable for directories, and > the above shouldn't apply. =A0'executable' actually means executable for > regular files, and the above should only apply indirectly: it is > executability that should be required to have an X perm bit set, and > then access() should just track the capability. =A0The usual weaseling > with "appropriate privilege" allows the X perm bits to have any control > on executablity including none, and at least the old POSIX spec doesn't > get in the way of this, since it doesn't mention the X perm bits in > connection with the exec functions. =A0The spec goes too far in the other > direction for the access function. Agreed (for all of the above). >> FreeBSD says: >> >> =A0 =A0Even if a process's real or effective user has appropriate privil= eges >> and >> =A0 =A0indicates success for X_OK, the file may not actually have execut= e per- >> =A0 =A0mission bits set. =A0Likewise for R_OK and W_OK. > > Perhaps it is time to fix this. =A0The part about X_OK never applied to a= ny > version of FreeBSD. =A0Perhaps it applied to the version o= f > execve() in Net/2 and 4.4BSD, but FreeBSD had to reimplement execve() and > it never had this bug. =A0But^2, the access() syscall and man page weren'= t > changed to match. =A0See the end of this reply for more details on execve= (). > See the next paragraph about more bugs in the above paragraph. > > Other bugs: > - R_OK and W_OK are far from likewise. =A0Everone knows that root can rea= d > =A0and write any file. Yes. Thankfully Linux also agrees on this point (I say this, because portability between Linux and BSD helps ease porting pains). > - The permission bits are relatively uninteresting. =A0access() should tr= ack > =A0the capability, not the bits. =A0The bits used to map to the capabilit= y > =A0directly for non-root, but now with ACLs, MAC, etc. they don't even do > =A0that. > - access(2) has no mention of ACLs, MAC, etc. No, sadly it doesn't (and of course POSIX leaves that open in the File permissions section, for good reason: http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap04.html#tag_= 04_04 ). That's the one thing that one of the folks on the bash list brought up that was a valid argument for using access(2), eaccess(2), or faccessat(2) vs stat(2). If you use a straight stat(2) call to determine whether or not a file is executable, the `hint' could be completely bogus as the file itself could be non-executable when the ACL or MAC denies the capability, whereas many implementations of access(2) support this additional permissions checking. > - See a recent PR about unifdefed CAPABILITIES code in vaccess(). =A0(The > =A0comment says that the code is always ifdefed out, but it now always > =A0unifdefed in.) =A0 I don't quite understand this code -- does it give > =A0all of ACLs, MAC and etc. at this level? Interestingly standard permissions bypass ACLs/MAC if standard permissions on the file/directory allow the requested permissions to succeed; note the return (0) vs the priv_check_cred calls -- this is where the the ACL/MAC for the inode is checked. This seems backwards, but I could be missing something.. >> =A0 This results in: >> >> =A0 sh/test - ok-ish (a guy on bash-bugs challenged the fact that the >> syscall was buggy based on the details returned). >> =A0 bash - broken (builtin test(1) always returns true) >> =A0 csh =A0- not really ok (uses whacky stat-like detection; doesn't >> check for ACLs, or MAC info) >> =A0 perl - ok (uses eaccess(2) for our OS). >> =A0 python - broken (uses straight access(2), so os.access is broken). ... > -current also has a MAC check here. =A0I can't see how vaccess(9) does an > equivalent check, or if it does, but if it did then we wouldn't need a > special MAC check here. Agreed. > % =A0 =A0 =A0 /* > % =A0 =A0 =A0 =A0* 1) Check if file execution is disabled for the filesys= tem that > this > % =A0 =A0 =A0 =A0* =A0 =A0 =A0file resides on. > % =A0 =A0 =A0 =A0* 2) Insure that at least one execute bit is on - otherw= ise root > % =A0 =A0 =A0 =A0* =A0 =A0 =A0will always succeed, and we don't want to h= appen unless the > % =A0 =A0 =A0 =A0* =A0 =A0 =A0file really is executable. > % =A0 =A0 =A0 =A0* 3) Insure that the file is a regular file. > % =A0 =A0 =A0 =A0*/ > % =A0 =A0 =A0 if ((vnodep->v_mount->mnt_flag & MNT_NOEXEC) || > % =A0 =A0 =A0 =A0 =A0 ((attr->va_mode & 0111) =3D=3D 0) || > % =A0 =A0 =A0 =A0 =A0 (attr->va_type !=3D VREG)) { > % =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (EACCES); > % =A0 =A0 =A0 } > > 0111 is an old spelling of the S_IX* bits. =A0We check these directly > since we know that VOP_ACCESS() is broken for root. =A0It is also good > to avoid calling VOP_ACCESS() first, since VOP_ACCESS() would record > our use of suser() privilege when in fact we won't use it. > > Yet 2 more bugs: not just point 2, but points 1 and 3 in the above > comment are undocumented in execve(2) and access(2). =A0The usual weaseli= ng > with "appropriate privilege" should allow these too, but (as I forgot > to mention above) I think "appropriate privilege" is supposed to be > documented somewhere, so the man pages are still missing details. Agreed on the former statement, and I understand the reasoning for the latter statement, but at least for 1., this is a feature of mount(2) (of course): MNT_NOEXEC Do not allow files to be executed from the file syste= m. ... Yes. The usual warning about the `hinting' being done by *access(2) is fine= :). -Garrett From owner-freebsd-standards@FreeBSD.ORG Wed Jul 21 10:47:30 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 4DBE1106566B; Wed, 21 Jul 2010 10:47:30 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id C3CEF8FC0A; Wed, 21 Jul 2010 10:47:29 +0000 (UTC) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6L8ehRa027766; Wed, 21 Jul 2010 18:40:43 +1000 Received: from c122-106-145-25.carlnfd1.nsw.optusnet.com.au (c122-106-145-25.carlnfd1.nsw.optusnet.com.au [122.106.145.25]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6L8ebFA010071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 18:40:39 +1000 Date: Wed, 21 Jul 2010 18:40:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Garrett Cooper In-Reply-To: Message-ID: <20100721162044.N7348@delplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: standards@FreeBSD.org, hackers@FreeBSD.org Subject: Re: 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: Wed, 21 Jul 2010 10:47:30 -0000 On Tue, 20 Jul 2010, Garrett Cooper wrote: > 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. This seems wrong for directories. It should say "... unless the file is 'executable'". 'executable' means searchable for directories, and the above shouldn't apply. 'executable' actually means executable for regular files, and the above should only apply indirectly: it is executability that should be required to have an X perm bit set, and then access() should just track the capability. The usual weaseling with "appropriate privilege" allows the X perm bits to have any control on executablity including none, and at least the old POSIX spec doesn't get in the way of this, since it doesn't mention the X perm bits in connection with the exec functions. The spec goes too far in the other direction for the access function. > 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. Perhaps it is time to fix this. The part about X_OK never applied to any version of FreeBSD. Perhaps it applied to the version of execve() in Net/2 and 4.4BSD, but FreeBSD had to reimplement execve() and it never had this bug. But^2, the access() syscall and man page weren't changed to match. See the end of this reply for more details on execve(). See the next paragraph about more bugs in the above paragraph. Other bugs: - R_OK and W_OK are far from likewise. Everone knows that root can read and write any file. - The permission bits are relatively uninteresting. access() should track the capability, not the bits. The bits used to map to the capability directly for non-root, but now with ACLs, MAC, etc. they don't even do that. - access(2) has no mention of ACLs, MAC, etc. - See a recent PR about unifdefed CAPABILITIES code in vaccess(). (The comment says that the code is always ifdefed out, but it now always unifdefed in.) I don't quite understand this code -- does it give all of ACLs, MAC and etc. at this level? > > 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? Mostly it is in vaccess(9). But execve() mostly doesn't use VOP_ACCESS(). Here is the FreeBSD-1 version, which is a bit shorter and thus easier to understand than the current version, and shows that FreeBSD has always required 1 exec bit for execve(): % /* % * Check permissions of file to execute. % * Return 0 for success or error code on failure. % */ % int % exec_check_permissions(iparams) % struct image_params *iparams; % { % struct proc *p = iparams->proc; % struct vnode *vnodep = iparams->vnodep; % struct vattr *attr = iparams->attr; % int error; % % /* % * Check number of open-for-writes on the file and deny execution % * if there are any. % */ % if (vnodep->v_writecount) { % return (ETXTBSY); % } % % /* Get file attributes */ % error = VOP_GETATTR(vnodep, attr, p->p_ucred, p); % if (error) % return (error); % -current also has a MAC check here. I can't see how vaccess(9) does an equivalent check, or if it does, but if it did then we wouldn't need a special MAC check here. % /* % * 1) Check if file execution is disabled for the filesystem that this % * file resides on. % * 2) Insure that at least one execute bit is on - otherwise root % * will always succeed, and we don't want to happen unless the % * file really is executable. % * 3) Insure that the file is a regular file. % */ % if ((vnodep->v_mount->mnt_flag & MNT_NOEXEC) || % ((attr->va_mode & 0111) == 0) || % (attr->va_type != VREG)) { % return (EACCES); % } 0111 is an old spelling of the S_IX* bits. We check these directly since we know that VOP_ACCESS() is broken for root. It is also good to avoid calling VOP_ACCESS() first, since VOP_ACCESS() would record our use of suser() privilege when in fact we won't use it. Yet 2 more bugs: not just point 2, but points 1 and 3 in the above comment are undocumented in execve(2) and access(2). The usual weaseling with "appropriate privilege" should allow these too, but (as I forgot to mention above) I think "appropriate privilege" is supposed to be documented somewhere, so the man pages are still missing details. % % /* % * Zero length files can't be exec'd % */ % if (attr->va_size == 0) % return (ENOEXEC); % % /* % * Disable setuid/setgid if the filesystem prohibits it or if % * the process is being traced. % */ % if ((vnodep->v_mount->mnt_flag & MNT_NOSUID) || (p->p_flag & STRC)) % attr->va_mode &= ~(VSUID | VSGID); % % /* % * Check for execute permission to file based on current credentials. % * Then call filesystem specific open routine (which does nothing % * in the general case). % */ % error = VOP_ACCESS(vnodep, VEXEC, p->p_ucred, p); % if (error) % return (error); We still use VOP_ACCESS() to handle the access checking in the usual case where 1 X bit is set. But this is not quite access(2) -- it uses the effective credentials, so is close to eaccess(2). % % error = VOP_OPEN(vnodep, FREAD, p->p_ucred, p); % if (error) % return (error); % % return (0); % } FreeBSD's man page also says: % SECURITY CONSIDERATIONS % The access() system call is a potential security hole due to race condi- % tions and should never be used. Set-user-ID and set-group-ID applica- % tions should restore the effective user or group ID, and perform actions % directly rather than use access() to simulate access checks for the real % user or group ID. The eaccess() system call likewise may be subject to % races if used inappropriately. This covers more than POSIX's point 2. Bruce From owner-freebsd-standards@FreeBSD.ORG Wed Jul 21 13:13:56 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 D07DE106566C; Wed, 21 Jul 2010 13:13:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 4F69F8FC14; Wed, 21 Jul 2010 13:13:55 +0000 (UTC) Received: from c122-106-145-25.carlnfd1.nsw.optusnet.com.au (c122-106-145-25.carlnfd1.nsw.optusnet.com.au [122.106.145.25]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6LDDqo5002550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 23:13:53 +1000 Date: Wed, 21 Jul 2010 23:13:52 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Garrett Cooper In-Reply-To: Message-ID: <20100721221551.B7582@delplex.bde.org> References: <20100721162044.N7348@delplex.bde.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-468481727-1279718032=:7582" Cc: standards@FreeBSD.org, hackers@FreeBSD.org Subject: Re: 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: Wed, 21 Jul 2010 13:13:56 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-468481727-1279718032=:7582 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 21 Jul 2010, Garrett Cooper wrote: > On Wed, Jul 21, 2010 at 1:40 AM, Bruce Evans wrote= : >> - See a recent PR about unifdefed CAPABILITIES code in vaccess(). =A0(Th= e >> =A0comment says that the code is always ifdefed out, but it now always >> =A0unifdefed in.) =A0 I don't quite understand this code -- does it give >> =A0all of ACLs, MAC and etc. at this level? > > Interestingly standard permissions bypass ACLs/MAC if standard > permissions on the file/directory allow the requested permissions to > succeed; note the return (0) vs the priv_check_cred calls -- this is > where the the ACL/MAC for the inode is checked. This seems backwards, > but I could be missing something.. I was wrong to say that vaccess() does most of the checking. This is only correct if there are no ACLs, etc. Otherwise, e.g., for ffs, the layering is more like VOP_ACCESS() -> ufs_access() =3D check r/o ffs check quota (bogusly in the clause whose comment says that it checks =09for a r/o fs, deep in the case statement for that clause. This =09was readable when that clause was only 16 lines long, but now =09it has messy locking for quotas, and large comments about this, =09so it is 44 lines long, with the number of lines for locking =09up from 4 to 32) check immutability. Another bug in access()'s man page is that it =09doesn't mention either immutability or the errno EPERM that at =09least ufs_access() returns for it. check acls call vaccess(). The MAC checks seem to be at the end of this and are unrelated to acls. But for exec_check_permissions(), the MAC checks are first. > ... >> % =A0 =A0 =A0 /* >> % =A0 =A0 =A0 =A0* 1) Check if file execution is disabled for the filesy= stem that >> this >> % =A0 =A0 =A0 =A0* =A0 =A0 =A0file resides on. >> % =A0 =A0 =A0 =A0* 2) Insure that at least one execute bit is on - other= wise root >> % =A0 =A0 =A0 =A0* =A0 =A0 =A0will always succeed, and we don't want to = happen unless the >> % =A0 =A0 =A0 =A0* =A0 =A0 =A0file really is executable. >> % =A0 =A0 =A0 =A0* 3) Insure that the file is a regular file. >> % =A0 =A0 =A0 =A0*/ >> % =A0 =A0 =A0 if ((vnodep->v_mount->mnt_flag & MNT_NOEXEC) || >> % =A0 =A0 =A0 =A0 =A0 ((attr->va_mode & 0111) =3D=3D 0) || >> % =A0 =A0 =A0 =A0 =A0 (attr->va_type !=3D VREG)) { >> % =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (EACCES); >> % =A0 =A0 =A0 } Your mail program seems to be responsible for making the above unreadable by changing tabs to hard \xa0's (which are displayed as tabs by my mail client(s?), but soft \xa0's followed by a space by my editor. >> 0111 is an old spelling of the S_IX* bits. =A0We check these directly Maybe the changes weren't of tabs. In this paragraphs, sentence breaks of 2 spaces got changed to 1 space followed by a hard \xa0. >> Yet 2 more bugs: not just point 2, but points 1 and 3 in the above >> comment are undocumented in execve(2) and access(2). =A0The usual weasel= ing >> with "appropriate privilege" should allow these too, but (as I forgot >> to mention above) I think "appropriate privilege" is supposed to be >> documented somewhere, so the man pages are still missing details. > > Agreed on the former statement, and I understand the reasoning for the > latter statement, but at least for 1., this is a feature of mount(2) > (of course): > > MNT_NOEXEC Do not allow files to be executed from the file syst= em. How is a newbie supposed to know to look in mount(2) to find extra failure cases? execve(2) even cross-references mount(8), but this was in connectio= n with the nosuid mount option in a wrong man page: % Index: execve.2 % =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D % RCS file: /home/ncvs/src/lib/libc/sys/execve.2,v % retrieving revision 1.11 % retrieving revision 1.12 % diff -u -2 -r1.11 -r1.12 % --- execve.2=0911 Jan 1998 21:43:38 -0000=091.11 % +++ execve.2=0927 Apr 1999 03:56:10 -0000=091.12 % @@ -31,5 +31,5 @@ % .\" % .\" @(#)execve.2=098.5 (Berkeley) 6/1/94 % -.\" $Id$ % +.\" $Id: execve.2,v 1.11 1998/01/11 21:43:38 alex Exp $ % .\" % .Dd June 1, 1994 % @@ -144,4 +144,9 @@ % .ne 1i % .Pp % +The set-ID bits are not honored if the respective file system has the % +.Ar nosuid % +option enabled or if the new process file is an interpreter file. Sysca= ll % +tracing is disabled if effective IDs are changed. % +.Pp % The new process also inherits the following attributes from % the calling process: % @@ -274,4 +279,6 @@ % .Xr exit 3 , % .Xr sysctl 3 , % +.Xr mount 1 , This dangling pointer was fixed to mount(8) in the next commit. But it should have been to mount(2) for MNT_NOSUID. % +.Xr ktrace 1 , % .Xr environ 7 % .Sh HISTORY I strongly dislike general references to man pages for 1 detail. There should be an Xr where each of the nosuid and tracing details is described and none at the end. There are actually many details of interest here, but how is a newbie going to notice this when the committers didn't? Details of interest are at least: - MNT_RDONLY (related to EROFS error) - MNT_NOSUID - MNT_NOEXEC - MNT_ACLS (new) - MNT_QUOTA Better yet, nmount() allows any number of new mount options that might affect access(), and you should have to read all the section 5 or 7 man pages for file systems to find them all (unless access() documents them all), but these man pages mostly don't exist and/or have few details, so you would have to read all section 8 man pages for mount utilities. Bruce --0-468481727-1279718032=:7582--