From owner-freebsd-fs Sat Mar 2 10:10: 8 2002 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3F51F37B41A for ; Sat, 2 Mar 2002 10:09:56 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g22I9iD15108; Sat, 2 Mar 2002 13:09:44 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 2 Mar 2002 13:09:43 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Byron Servies Cc: freebsd-fs@freebsd.org Subject: Re: Retrieving a list of ACLs for a file In-Reply-To: <20020302100050.A15624@pacang.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 2 Mar 2002, Byron Servies wrote: > On March 01, 2002 at 16:52, Robert Watson wrote: > > > > Unfortunately, the POSIX.1e API doesn't define a way to get a list of > > valid ACL types for a particular filesystem object (or even a filesystem). > > For the time being, it's probably sufficient to assume that there will > > only be ACL_TYPE_ACCESS and ACL_TYPE_DEFAULT ACLs present on filesystems. > > Other ACL constants have been tentatively assigned, but are not used. > > I was looking around some more last week and noticed that the posix acl > support is built upon a more generic extattr facility. Instead of > backing up the posix acl's directly, should I instead be using this > facility to backup any possible additional attributes on a file? > > Since this is a freebsd api, I could add the function necessary to > collect a complete list, if one does not exist yet. > > Preferences? > > Thanks for the advice, Byron, Yes, indeed, the ACL mechanism for UFS is based on a general purpose extended attribute service. However, that may not be the case for all filesystems. Extended attributes currently exist in two namespaces: system, and user. My suggestion would be to use the following strategy: - Back up all available user extended attributes for a file system node. Currently, I don't know of anyone deploying/using user namespace attributes. Right now, our API supports listing the attributes on a node, but it's not implemented. I think Brian Feldman has that on his TODO list, but I should check. - Don't back up system namespace extended attributes, instead, back up the higher level primitive (such as ACL) using the defined higher level API. Generally speaking, backing up the higher level primitive will result in a portable representation, whereas backing up the lower level primitive may (and probably will) not. The various implementations I've looked at so far tend to actually store the ACL using the results of acl_to_text(), so that the results can be restored on another POSIX.1e-supporting system that might use a different on-disk representation (perhaps due to size differences in uid_t, gid_t, mode_t, etc). I think that we also don't have an implementation of the pathconf() call for POSIX.1e ACLs, but that should be easy to fix as the new mount API becomes available. In that case, when backing up the file system, you should be able to query the availability of EA and ACL services, then if the filesystem supports them, pull out the user EAs, and the POSIX.1e ACLs (default and access for directories, otherwise generally access). With the UFS2 implementation, this should all get a lot faster. I'll prod Brian to make sure we get the ability to list EAs in the next week or so. 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-fs" in the body of the message