From owner-freebsd-current Sun Dec 2 15: 9:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 533AE37B41A for ; Sun, 2 Dec 2001 15:09:44 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fB2N9Ri22763; Sun, 2 Dec 2001 18:09:28 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 2 Dec 2001 18:09:26 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Daniel Rock Cc: current@freebsd.org Subject: Re: Inconsistencies in *stat() for files with ACLs In-Reply-To: <3C0A8AE7.4CCD8B42@t-online.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 2 Dec 2001, Daniel Rock wrote: > Hi, > > lstat(), fstat(), stat() returned structure is inconsistent and > misleading if the file has ACLs associated with it. That behavior is defined by POSIX.1e, so it's what we implemented; you'll find that the same behavior is present on other platforms with conforming implementations. It actually does make some sense, when you think about it: POSIX.1e requires that the group permissions returned by stat() be the ACL_MASK entry if an extended ACL is present. That means that stat() displays the "worst case" protections. Likewise, the spec requires that chmod() modify the ACL_MASK entry if an extended ACL is present, which gives you conservative behavior: if group write is removed, "the right thing happens". For example, if you chmod 0600 on the file, it "works": POSIX.1e considers the "extended ACL" to expand the group entry of the permissions. That said, I won't argue it's intuitive unless you know about the behavior already, and it probably should be documented in the stat(2) man page. If you're interested in discussing these semantics, it might be worth raising it on the POSIX.1e mailing list (posix1e@cyrus.watson.org). A number of people involved in writing the spec are there, and in the past it has been a successful forum for discussing ambiguities (not to mention mistakes) in the spec. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message