From owner-freebsd-security@FreeBSD.ORG Tue Sep 20 10:01:30 2005 Return-Path: X-Original-To: freebsd-security@FreeBSD.org Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1564316A41F for ; Tue, 20 Sep 2005 10:01:30 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DF7843D48 for ; Tue, 20 Sep 2005 10:01:29 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id D319F46B3B for ; Tue, 20 Sep 2005 06:01:28 -0400 (EDT) X-Return-Path: X-Received: from cyrus.watson.org ([unix socket]) by cyrus.watson.org (Cyrus v2.1.17) with LMTP; Sat, 17 Sep 2005 08:19:32 -0400 X-Sieve: CMU Sieve 2.2 X-Received: by cyrus.watson.org (Postfix) id 1AAFE46B97; Sat, 17 Sep 2005 08:19:32 -0400 (EDT) X-Delivered-To: trustedbsd-discuss-outgoing@cyrus.watson.org X-Received: by cyrus.watson.org (Postfix, from userid 54) id 1905646B96; Sat, 17 Sep 2005 08:19:32 -0400 (EDT) X-Original-To: trustedbsd-discuss@TrustedBSD.org X-Delivered-To: trustedbsd-discuss@cyrus.watson.org X-Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id DB23E46B8B; Sat, 17 Sep 2005 08:19:31 -0400 (EDT) Date: Sat, 17 Sep 2005 13:19:31 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: trustedbsd-discuss@TrustedBSD.org Message-ID: <20050917125528.M11664@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-trustedbsd-discuss@cyrus.watson.org Precedence: bulk ReSent-Date: Tue, 20 Sep 2005 11:01:18 +0100 (BST) Resent-From: robert Resent-To: freebsd-security@FreeBSD.org ReSent-Subject: File System ACLs: Where to go from here in FreeBSD? ReSent-Message-ID: <20050920110118.W29579@fledge.watson.org> Cc: astrodog@gmail.com Subject: File System ACLs: Where to go from here in FreeBSD? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2005 10:01:30 -0000 The FreeBSD ACL implementation is currently based on a late POSIX.1e draft, and is similar in functionality to the ACL support in Solaris, IRIX, and Linux. It was developed along a similar timeline to the Linux ACL support, and Andreas and I chatted a fair amount along the way so the parallels are strong -- in fact, the Samba ACL support is almost identical, and the ACL API man pages on Linux are directly derived from our ACL man pages (and maybe some of the code?). Differences lie primarily in three areas: (1) We follow the POSIX.1e specification for file creation modes, in which the ACL and umask are combined with the cmode to generate a conservative ACL. This was the same as IRIX, but different from Solaris; Linux adopted the Solaris model. Since then, IRIX has (I believe) also switched to the Solaris model. Our model is "conservative" in that it will never offer broader rights on a file than the umask permits, but it turns out to be quite useful in some environments to allow the ACL on a directory to overide the umask of a program writing files there. (2) We offer a few fewer support routines in user space, such as routines to copy an ACL from one file to another. This has been getting gradually fleshed out over time. (3) We don't offer Solaris-compatible NFSv3 extensions to allow remote management of ACLs via NFS, although the ACLs are enforced on the server so they are "implemented". I'm not sure if these patches were merged to Linux or not, but they were floating around for quite a while. As I see it, there are two directions we can take file system ACL support, and here-in lies the Big Question: (a) We can continue down the POSIX.1e branch of the ACL world, continuing to enhance and refine our support. For example, continuing to flesh out a few missing spots in user space, move over to the now predominent model for generating new file permissions (non-conservative ACL override), implement NFSv3 RPCs. This is some, work, but not a huge amount of work. Or, the a new option that has basically become feasible over the last six years since the POSIX.1e direction was the one we selected: (b) We can consider a migration to NT/NFSv4-style ACLs, which is the route that Darwin has taken. They use the FreeBSD user space ACL library and POSIX.1e interfaces, but use ACLs with more NT-like semantics. In particular, they have notions of taking ownership, slightly finer grained directory controls, etc. This is a lot of work. Option (b) is an interesting new choice as compared to 1999, when NTFS ACLs were in the distinct minority in terms of the syntax and semantics they offered. However, they become much more appealing if we consider that there appears to be a much clearer mapping from NTFS ACLs to NFSv4 ACLs than there is from POSIX.1e ACLs to NFSv4 ACLs. And the fact that Mike Smith at Apple has taken the time to make it sit behind our library for the Darwin implementation on HFS+, etc, is also quite interesting. When I implemented the library, it was my hope that it would support that sort of thing, but we never actually tried :-). If we don't start considering a move to Darwin/NTFS ACLs, then we run into a problem when it comes to implementing NFSv4 ACLs: the mapping and behavior is rather poor and unclear. There's an ID on the topic, which I basically read as saying "This is all rather hard and rather non-ideal". Apple has identified that, for them, compatibility with NT (and possibly NFSv4?) is the way to go, and they may be right. On the other hand, the result is much reduced possibility of clean interoperability with Linux, Solaris, IRIX, and so on. So there's a definite trade-off. If we do make this change, I'd like to also simultaneously consider a change to add an array size field in the ACL structure -- right now, we have a fixed maximum size, and there's a field that says how much of that space is used, but not how much space is available. If we want to support longer ACLs in the future, having a variable array size will improve efficiency and add flexibility. If we want to consider switching to the Darwin ACL model, it sounds like the strategy would be something like the following: (1) Investigate the model closely, and compare it to NTFS. Identify whether any of the significant semantic differences is a problem. (2) Investigate the NFSv4 model closely, and decide if there is a clean and useful mapping or not. If there are nits, approach Apple and decide whether the nits are necessary or not. (3) Produce an implementation on top of UFS2 to experiment with, and see what happens. Specifically, how our current in-kernel APIs and data structures work with it. (4) See whether there is a sensible mapping from existing POSIX.1e ACLs to the newer ACL style, which could be performed at run-time when reading an existing ACL-enabled partition. Specifically, in the long term will we need to support two ACL modes -- a legacy POSIX.1e mode and a new Darwin/NTFS/NFSv4 mode, or can we run entirely in the new mode and run-time translate old ACLs to support a migration path? (6) Investigate what the implications are for applications, especially relating to supporting two ACL models. Will applications get stuck figuring out how they co-exist, or can the kernel help to hide it? (7) Investigate what the implications are for users, who may find that the semantic changes are significant -- and disruptive, potentially. Apple has chosen to provide separate tools for managing ACLs, rather than the POSIX.2e ones, and we might find the same is necessary. It would be interesting to know if systems other than Darwin have started exploring this route. For example, Sun has always been quite interested in NFSv4 -- are they considering or have they made an ACL change that corresponds with the integration of NFSv4 support? My feeling is that NFSv4 might be the compelling argument to consider a migration, and that if we are going to migrate, the sooner we get started with the implementation work, the better. Any thoughts here are welcome. Robert N M Watson To Unsubscribe: send mail to majordomo@trustedbsd.org with "unsubscribe trustedbsd-discuss" in the body of the message