From owner-posix1e@FreeBSD.ORG Fri Feb 24 00:39:18 2006 Return-Path: X-Original-To: posix1e@FreeBSD.org Delivered-To: posix1e@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 498F416A420 for ; Fri, 24 Feb 2006 00:39:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0289243D45 for ; Fri, 24 Feb 2006 00:39:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: by cyrus.watson.org (Postfix) id 1578B46BEC; Thu, 23 Feb 2006 19:39:01 -0500 (EST) Delivered-To: posix1e@cyrus.watson.org Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1288446BE2 for ; Thu, 23 Feb 2006 19:39:01 -0500 (EST) Date: Fri, 24 Feb 2006 00:43:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: posix1e@cyrus.watson.org Message-ID: <20060224004250.X33959@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: POSIX.1e mailing list moves to lists.FreeBSD.org mailman server X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2006 00:39:18 -0000 To those of you still subscribed, despite long silences followed by brief flurries, to the posix1e mailing list: the various and sundry TrustedBSD.org lists have been moved to the FreeBSD Project's mailman mailing list server. This provides a number of benefits over the Majordomo server previously run on cyrus.watson.org, including web-based list administration, web-based list subscription management, and web-based mailing list archives. I've now moved all subscriptions over. All posting current posting addresses will remain valid, but the new posting address should you prefer to use that is posix1e@FreeBSD.org. The topic of the list will remain discussion of the withdrawn POSIX.1e draft specification. The URL to manage your subscription is: http://lists.freebsd.org/mailman/listinfo/posix1e While things are mostly quiet on this list, I hope you'll remain subscribed as everyone's contributions are welcome when POSIX.1e questions do come up. Please let me know if there are any problems. Thanks, Robert N M Watson From owner-posix1e@FreeBSD.ORG Sat Mar 11 01:17:42 2006 Return-Path: X-Original-To: posix1e@freebsd.org Delivered-To: posix1e@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DDD116A43E for ; Sat, 11 Mar 2006 01:17:42 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B434250909 for ; Sat, 11 Mar 2006 01:10:51 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from freebsd.org (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id k2B1ApOZ010966; Fri, 10 Mar 2006 17:10:51 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <44122398.3050801@freebsd.org> Date: Fri, 10 Mar 2006 17:10:48 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: posix1e@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: jheinonen@users.sourceforge.net Subject: Archiving/transferring Extended Attributes... X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2006 01:17:42 -0000 All, As the developer/maintainer of libarchive and bsdtar, I've been very interested in finding good ways to archive, transfer, and restore all kinds of file metadata, including ACLs and extended attributes. Libarchive/bsdtar supports ACLs (following the approach used by Joerg Schilling in 'star', which addresses some problems with the POSIX.1e draft), but does not yet have full support for extended attributes. Jaakko Heinonen recently sent me some patches to add extended attribute support for Linux (which should be easy to extend to other platforms), but I have a few questions that people on this list might be able to help with. First, here is my basic understanding (if anyone can point out systems where these assumptions fail, I'd much appreciate): * An "extended attribute" is essentially a key/value pair. * The value is an arbitrary block of binary data. * Values are almost always less than a few kilobytes long. Values longer than a megabyte are very unusual. * The key is a text name (? see below ?). * Keys are organized into "namespaces," which can be rendered using dot-separated tuples: "system.foo" is in the "system" namespace, "user.bar" is in the "user" namespace. Here are some of my questions: * Are keys always text? Are they limited to ASCII? Can they always be translated to UTF-8? (Background: I'm basing my work on "pax extended format" which uses UTF-8 very heavily.) * What keys should be archived for single-system backup/restore? (I would presume "all," but I fear there may be extended attributes used internally by some systems that should not be touched or cannot be changed.) * What keys should be archived for cross-system copying of files? (I would assume the "system" namespace should not be copied across systems. In particular, I know that FreeBSD's extended attribute system stores ACLs and other standard data in extended attributes; I'm not entirely comfortable backing up such data in two different forms.) * Are there platform-specific namespaces that should not be archived? (I've been told that "xfsroot" namespace on Linux should not be touched.) * My understanding right now is that the primary client of extended attributes on Linux and FreeBSD is the Samba file server. I believe that just archiving the "user" namespace would suffice for Samba. Do other applications have other requirements? Does anyone here have experience designing a backup/restore/transfer system for extended attributes? Any insight or suggestions are appreciated, Tim Kientzle mailto:kientzle@freebsd.org From owner-posix1e@FreeBSD.ORG Sun Mar 19 19:54:17 2006 Return-Path: X-Original-To: posix1e@freebsd.org Delivered-To: posix1e@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DD4016A401 for ; Sun, 19 Mar 2006 19:54:17 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7694343D5F for ; Sun, 19 Mar 2006 19:54:13 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from freebsd.org (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id k2JJsCOZ067273; Sun, 19 Mar 2006 11:54:12 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <441DB6DE.5070108@freebsd.org> Date: Sun, 19 Mar 2006 11:54:06 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: posix1e@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Jaakko Heinonen Subject: RFC: Extended Attribute Support for tar X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2006 19:54:17 -0000 To the members of the POSIX.1e mailing list: Jaakko Heinonen and I have developed the following approach for storing extended attributes in "pax extended format" (an extension of tar format) archives. This is implemented in libarchive-1.2.51 on : Background: pax extended format supports a general key/value mechanism in which keys and values are stored as UTF8 strings separated by an '=' character. Proposal: POSIX-style extended attributes are stored as separate pax attributes as follows: The pax name is LIBARCHIVE.xattr.. (Rationale: pax standard requires non-standard extensions be prefixed with an all-uppercase vendor name.) The extended attribute name (including namespace) is encoded using URL-encoding (specifically, '%' becomes '%25', '=' becomes '%3D', and all non-ASCII characters are similarly encoded). (Rationale: The encoding here avoids any problems from '=' characters appearing in the extended attribute name.) Note that the result of URL-encoding will be ASCII and hence already UTF-8. (Note: ASCII names that do not contain '%' or '=' appear in the archive exactly as they appear in the filesystem.) The value is base64 encoded (MIME encoding, except without line breaks and the last group is not padded). (Rationale: extended attribute values are binary and must not be modified; base64 encoding is widely understood.) By default, "system" and "root" namespaces are not archived. (Rationale: These are often not accessible to regular users. They are often used for ACLs and other properties that should be archived using other mechanisms.) Comparison with other approaches: Joerg Shilling's "star" implementation is the only "tar" program that I know of that attempts to archive extended attributes. It uses an approach similar to the above, but it does not encode the attribute name (hence cannot handle attributes with '=' or non-ASCII bytes in the name) and stores the attribute value as raw binary (which contradicts the pax specification which requires UTF8). Any comments or feedback are greatly appreciated. Tim Kientzle mailto:kientzle@freebsd.org From owner-posix1e@FreeBSD.ORG Mon Mar 20 19:21:07 2006 Return-Path: X-Original-To: posix1e@freebsd.org Delivered-To: posix1e@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2344B16A424; Mon, 20 Mar 2006 19:21:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA97143D45; Mon, 20 Mar 2006 19:21:06 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 08F5046BCE; Mon, 20 Mar 2006 14:21:06 -0500 (EST) Date: Mon, 20 Mar 2006 19:21:05 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tim Kientzle In-Reply-To: <441DB6DE.5070108@freebsd.org> Message-ID: <20060320191937.N67379@fledge.watson.org> References: <441DB6DE.5070108@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: posix1e@freebsd.org, Jaakko Heinonen Subject: Re: RFC: Extended Attribute Support for tar X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2006 19:21:07 -0000 On Sun, 19 Mar 2006, Tim Kientzle wrote: > By default, "system" and "root" namespaces are not archived. (Rationale: > These are often not accessible to regular users. They are often used for > ACLs and other properties that should be archived using other mechanisms.) > > Comparison with other approaches: Joerg Shilling's "star" implementation is > the only "tar" program that I know of that attempts to archive extended > attributes. It uses an approach similar to the above, but it does not encode > the attribute name (hence cannot handle attributes with '=' or non-ASCII > bytes in the name) and stores the attribute value as raw binary (which > contradicts the pax specification which requires UTF8). > > Any comments or feedback are greatly appreciated. This all sounds pretty reasonable to me, especially the decision regarding system attributes. Since you say "by default", I assume you intend to provide a way to optionally backup and restore attributes in other name spaces if requested? Robert N M Watson From owner-posix1e@FreeBSD.ORG Tue Mar 21 07:56:45 2006 Return-Path: X-Original-To: posix1e@FreeBSD.org Delivered-To: posix1e@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D046316A400; Tue, 21 Mar 2006 07:56:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59EC243D46; Tue, 21 Mar 2006 07:56:45 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 07A7546C72; Tue, 21 Mar 2006 02:56:44 -0500 (EST) Date: Tue, 21 Mar 2006 07:56:43 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tim Kientzle In-Reply-To: <441FADAE.1040304@kientzle.com> Message-ID: <20060321075405.D67379@fledge.watson.org> References: <441DB6DE.5070108@freebsd.org> <20060320191937.N67379@fledge.watson.org> <441FADAE.1040304@kientzle.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: posix1e@FreeBSD.org, Jaakko Heinonen , Tim Kientzle Subject: Re: RFC: Extended Attribute Support for tar X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2006 07:56:45 -0000 On Mon, 20 Mar 2006, Tim Kientzle wrote: > Robert Watson wrote: >> On Sun, 19 Mar 2006, Tim Kientzle wrote: >> >>> By default, "system" and "root" namespaces are not archived. >> >> This all sounds pretty reasonable to me, especially the decision regarding >> system attributes. Since you say "by default", I assume you intend to >> provide a way to optionally backup and restore attributes in other name >> spaces if requested? > > I'm trying to figure that part out. For example, I'm wary of backing up > FreeBSD ACL information in two different forms (as ACL and as extended > attribute). I seem to have read that XFS uses the "root" namespace for > filesystem private info that should not be backed up and restored, much less > copied across systems. > > Are there any conventions about these namespaces? My understanding is pretty much yours -- the FreeBSD system/user model is very much modeled on the IRIX model, in which one name space is intended for kernel components to access, supporting a variety of semantic-rich attributes, and the other is for opaque data stored by applications. In that view of the world, you want to back up attributes using the defined APIs, which among other things, have something to say about returning the data in portable formats (i.e., converting the ACL to portable text). However, it would be useful to be able to request the backup and restore of specific system attributes by name for situations where there may not be a portable API -- i.e., if there's a kernel component storing MD5 checksums of executables in the system name space, it would be nice to be able to request they be backed up and restored with the files. Robert N M Watson From owner-posix1e@FreeBSD.ORG Tue Mar 21 07:39:37 2006 Return-Path: X-Original-To: posix1e@FreeBSD.org Delivered-To: posix1e@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3552016A400; Tue, 21 Mar 2006 07:39:37 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E94A43D46; Tue, 21 Mar 2006 07:39:36 +0000 (GMT) (envelope-from tim@kientzle.com) Received: from kientzle.com (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id k2L7dZOZ077658; Mon, 20 Mar 2006 23:39:36 -0800 (PST) (envelope-from tim@kientzle.com) Message-ID: <441FADAE.1040304@kientzle.com> Date: Mon, 20 Mar 2006 23:39:26 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <441DB6DE.5070108@freebsd.org> <20060320191937.N67379@fledge.watson.org> In-Reply-To: <20060320191937.N67379@fledge.watson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Mar 2006 13:25:26 +0000 Cc: posix1e@FreeBSD.org, Jaakko Heinonen , Tim Kientzle Subject: Re: RFC: Extended Attribute Support for tar X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2006 07:39:37 -0000 Robert Watson wrote: > On Sun, 19 Mar 2006, Tim Kientzle wrote: > >> By default, "system" and "root" namespaces are not archived. > > This all sounds pretty reasonable to me, especially the decision > regarding system attributes. Since you say "by default", I assume you > intend to provide a way to optionally backup and restore attributes in > other name spaces if requested? I'm trying to figure that part out. For example, I'm wary of backing up FreeBSD ACL information in two different forms (as ACL and as extended attribute). I seem to have read that XFS uses the "root" namespace for filesystem private info that should not be backed up and restored, much less copied across systems. Are there any conventions about these namespaces? Tim From owner-posix1e@FreeBSD.ORG Thu Apr 24 03:47:12 2008 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E7301065670; Thu, 24 Apr 2008 03:47:11 +0000 (UTC) (envelope-from infofarmer@FreeBSD.org) Received: from heka.cenkes.org (heka.cenkes.org [208.79.80.110]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4478FC16; Thu, 24 Apr 2008 03:47:11 +0000 (UTC) (envelope-from infofarmer@FreeBSD.org) Received: from amilo.cenkes.org (ppp83-237-169-4.pppoe.mtu-net.ru [83.237.169.4]) (Authenticated sender: sat) by heka.cenkes.org (Postfix) with ESMTPSA id 10680242F8D7; Thu, 24 Apr 2008 07:30:57 +0400 (MSD) Date: Thu, 24 Apr 2008 07:30:51 +0400 From: Andrew Pantyukhin To: posix1e@FreeBSD.org, trustedbsd-discuss@FreeBSD.org Message-ID: <20080424033043.GD1449@amilo.cenkes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-OS: FreeBSD 8.0-CURRENT amd64 User-Agent: Mutt/1.5.17 (2007-11-01) X-Mailman-Approved-At: Thu, 24 Apr 2008 04:03:57 +0000 Cc: Subject: Posix1e funcs in FreeBSD X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: infofarmer@FreeBSD.org List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2008 03:47:12 -0000 When looking at our ACLs, and how 3d-party code might use them (e.g. python libacl for ACL support in rdiff-backup), I see there are missing parts. For example, acl_copy_ext/int, acl_size are missing. These three are present in Linux. My question is, what's the status of posix1e-related work in FreeBSD and TrustedBSD. Is it intentionally slowed down, or will new work be accepted? If the latter, what's the right place to send patches to and discuss them? From owner-posix1e@FreeBSD.ORG Thu Apr 24 06:58:32 2008 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BEBA106566C; Thu, 24 Apr 2008 06:58:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 715A58FC17; Thu, 24 Apr 2008 06:58:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7161F46B84; Thu, 24 Apr 2008 02:40:00 -0400 (EDT) Date: Thu, 24 Apr 2008 07:40:00 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrew Pantyukhin In-Reply-To: <20080424033043.GD1449@amilo.cenkes.org> Message-ID: <20080424073303.Y9282@fledge.watson.org> References: <20080424033043.GD1449@amilo.cenkes.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: posix1e@FreeBSD.org, trustedbsd-discuss@FreeBSD.org Subject: Re: Posix1e funcs in FreeBSD X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2008 06:58:32 -0000 On Thu, 24 Apr 2008, Andrew Pantyukhin wrote: > When looking at our ACLs, and how 3d-party code might use them (e.g. python > libacl for ACL support in rdiff-backup), I see there are missing parts. For > example, acl_copy_ext/int, acl_size are missing. These three are present in > Linux. > > My question is, what's the status of posix1e-related work in FreeBSD and > TrustedBSD. Is it intentionally slowed down, or will new work be accepted? > If the latter, what's the right place to send patches to and discuss them? My recollection is a bit hazy, as it's been several years, but I believe that we decided not to implement those interfaces on the basis that the standard didn't say what the external storage format was. As a result, there was no portable way to implement the functions. Instead, we recommend using acl_from_text(3) and acl_to_text(3), which do have defined formats. If you are interested in implementing those calls, my initial recommendation would be to make them wrappers around the text interfaces, although it would be worth looking at how other systems do it (warning: other systems may not all do it the same way). The reason ACL work has slowed down (virtually stopped) is that it's essentially done. There are probably a few bits and pieces in the system that would benefit from better ACL support -- for example, I have a sneaking suspicion that one or two utilities fail to properly preserve ACLs (nvi?). The most recent parts to gain proper ACL support were tar/libarchive and dump, so there is still stuff going on. We'd happily accept contributions to improve deficiencies, ideally in the form of patches. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-posix1e@FreeBSD.ORG Fri Apr 25 04:57:29 2008 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B729A1065675; Fri, 25 Apr 2008 04:57:29 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8B04C8FC21; Fri, 25 Apr 2008 04:57:29 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.128] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id m3P4Hxtv052969; Thu, 24 Apr 2008 21:17:59 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <48115B77.1000905@freebsd.org> Date: Thu, 24 Apr 2008 21:17:59 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: infofarmer@freebsd.org References: <20080424033043.GD1449@amilo.cenkes.org> In-Reply-To: <20080424033043.GD1449@amilo.cenkes.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: posix1e@freebsd.org, trustedbsd-discuss@freebsd.org Subject: Re: Posix1e funcs in FreeBSD X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2008 04:57:29 -0000 > My question is, what's the status of posix1e-related work in > FreeBSD and TrustedBSD. Is it intentionally slowed down, or will > new work be accepted? If the latter, what's the right place to > send patches to and discuss them? This mailing list is an ideal place to discuss it, and of course the freebsd-hackers and freebsd-current mailing lists are good places to discuss work you'd like to do. As Robert said, the ACL support is in pretty good shape, at least in terms of the basic utilities and system calls. There's work to do still in getting support into more utilities, of course. (I think FreeBSD may be in better shape than Linux here, though. A number of distributions still don't ship libacl by default.) Extended attribute support is somewhat rougher. (I still haven't found time to finish off the FreeBSD-specific hooks for libarchive's extended attribute support, for instance.) Beyond posix1e, there's a real need for people to work on NFSv4/NTFS ACLs. Most of the commercial folks (IBM, HP, Sun) already support them and they're a key feature for full Samba support. One of the FreeBSD projects being sponsored by Google Summer of Code is going to work on getting basic NFSv4 ACL support into FreeBSD but there will doubtless be plenty of ongoing work to get that integrated cleanly into all of the userland applications. Cheers, Tim Kientzle From owner-posix1e@FreeBSD.ORG Wed May 14 19:04:39 2008 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 687521065679 for ; Wed, 14 May 2008 19:04:39 +0000 (UTC) (envelope-from pedro@ambientworks.net) Received: from protection.cx (protection.cx [209.242.20.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5580B8FC16 for ; Wed, 14 May 2008 19:04:39 +0000 (UTC) (envelope-from pedro@ambientworks.net) Received: by protection.cx (Postfix, from userid 1001) id 542F719E6E3; Wed, 14 May 2008 13:48:20 -0500 (CDT) Date: Wed, 14 May 2008 15:48:20 -0300 From: Pedro Martelletto To: posix1e@FreeBSD.org Message-ID: <20080514184820.GA25967@static.protection.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailman-Approved-At: Wed, 14 May 2008 19:15:44 +0000 Subject: Fix freeing of ACLs in 'setfacl' X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2008 19:04:39 -0000 Hi, There seems to be a double free condition in 'setfacl', as follows: Initially, 'acl' (an 'acl_t *') is allocated, and its ACCESS_ACL and DEFAULT_ACL fields are passed to the 'libc' ACL routines for subsequent allocation. If the '-m' option (merge existing ACL with a new one) is specified, then 'set_acl_mask()' will be called and passed one of the two ACLs. This function, in turn, replaces this given ACL structure by another, freshly allocated. However, the pointer in the 'acl' variable in the caller is not updated. The caller then proceeds to free the ACL, incurring in a double free condition. This happens for every regular file, directory or symbolic link being operated on, so the consequences are more easily visible when multiple file system objects are involved. A proposed fix is implemented below. Thank you for your attention, -p. (Please directly include my address in eventual replies, as I'm not subscribed to this list.) Index: setfacl.c =================================================================== RCS file: /home/ncvs/src/bin/setfacl/setfacl.c,v retrieving revision 1.13 diff -u -p -r1.13 setfacl.c --- setfacl.c 26 Feb 2007 00:42:17 -0000 1.13 +++ setfacl.c 14 May 2008 18:22:18 -0000 @@ -245,10 +245,13 @@ main(int argc, char *argv[]) continue; } - if (acl_type == ACL_TYPE_ACCESS) + if (acl_type == ACL_TYPE_ACCESS) { final_acl = acl[ACCESS_ACL]; - else + acl_free(acl[DEFAULT_ACL]); + } else { final_acl = acl[DEFAULT_ACL]; + acl_free(acl[ACCESS_ACL]); + } if (need_mask && (set_acl_mask(&final_acl) == -1)) { warnx("failed to set ACL mask on %s", file->filename); @@ -269,8 +272,7 @@ main(int argc, char *argv[]) } } - acl_free(acl[ACCESS_ACL]); - acl_free(acl[DEFAULT_ACL]); + acl_free(final_acl); free(acl); } From owner-posix1e@FreeBSD.ORG Sat Jun 28 09:33:18 2008 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10D2A106566B for ; Sat, 28 Jun 2008 09:33:18 +0000 (UTC) (envelope-from iusty@k1024.org) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id 96B798FC0C for ; Sat, 28 Jun 2008 09:33:17 +0000 (UTC) (envelope-from iusty@k1024.org) Received: by mu-out-0910.google.com with SMTP id i2so232907mue.3 for ; Sat, 28 Jun 2008 02:33:16 -0700 (PDT) Received: by 10.103.206.12 with SMTP id i12mr1078752muq.33.1214643927462; Sat, 28 Jun 2008 02:05:27 -0700 (PDT) Received: from teal.hq.k1024.org ( [84.75.116.141]) by mx.google.com with ESMTPS id y2sm11154523mug.1.2008.06.28.02.05.26 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 Jun 2008 02:05:26 -0700 (PDT) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 22E4240A113; Sat, 28 Jun 2008 11:05:25 +0200 (CEST) Date: Sat, 28 Jun 2008 11:05:24 +0200 From: Iustin Pop To: posix1e@FreeBSD.org Message-ID: <20080628090524.GA5399@teal.hq.k1024.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.18 (2008-05-17) Subject: userland acl_valid() wierdness X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2008 09:33:18 -0000 Hi there, While trying to improve the python bindings for acls on 7.0-release, I came up upon something that seems strange to me. Basically, an acl that contains an ACL_USER or ACL_GROUP entry with the qualifier the same as the current user or group(s?) is declared invalid by the userland, although this in my understanding of the specs is not prohibited anywhere, and to me it doesn't make sense (an ACL should protect from changes in the ownership of the file, for example). Furthermore, the kernel has completely different checks, although the comments in lib/libc/posix1e/acl_support.c say: * _posix1e_acl_check -- given an ACL, check its validity. This is * mirrored from code in sys/kern/kern_acl.c, and if changes are made in * one, they should be made in the other also. What the kernel does is simply to set the qualifier for ACL_USER_OBJ and ACL_GROUP_OBJ to ACL_UNDEFINED_ID, which seems sane, and then it checks the qualifier for ACL_USER to be not equal to UNDEFINED_ID, which is much more reasonable than the userspace code. Do I misunderstand here the usage? Sample program: #include #include #include #include #include int main() { acl_t ma; acl_entry_t e; uid_t user=getuid(); ma = acl_from_text("u::rw,g::r,o::-"); if(ma==NULL) perror("acl_from_text"); if(acl_valid(ma)==-1) perror("initial acl is not valid"); if(acl_create_entry(&ma, &e)==-1) perror("acl_create_entry"); if(acl_set_tag_type(e, ACL_USER)==-1) perror("acl_set_tag_type"); if(acl_set_qualifier(e, &user)==-1) perror("acl_set_qualifier"); if(acl_calc_mask(&ma)==-1) perror("acl_calc_mask"); if(acl_valid(ma)==-1) perror("modified acl is not valid"); } in this example, the acl_calc_mask and acl_valid will fail unless the getuid() is changed to getuid()+1. thanks, iustin From owner-posix1e@FreeBSD.ORG Sun Jul 13 16:20:53 2008 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE35F106564A for ; Sun, 13 Jul 2008 16:20:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4138FC12 for ; Sun, 13 Jul 2008 16:20:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5938846C8E; Sun, 13 Jul 2008 12:01:06 -0400 (EDT) Date: Sun, 13 Jul 2008 17:01:06 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Iustin Pop In-Reply-To: <20080628090524.GA5399@teal.hq.k1024.org> Message-ID: <20080713165616.J9673@fledge.watson.org> References: <20080628090524.GA5399@teal.hq.k1024.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: posix1e@FreeBSD.org Subject: Re: userland acl_valid() wierdness X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2008 16:20:53 -0000 On Sat, 28 Jun 2008, Iustin Pop wrote: > While trying to improve the python bindings for acls on 7.0-release, I came > up upon something that seems strange to me. > > Basically, an acl that contains an ACL_USER or ACL_GROUP entry with the > qualifier the same as the current user or group(s?) is declared invalid by > the userland, although this in my understanding of the specs is not > prohibited anywhere, and to me it doesn't make sense (an ACL should protect > from changes in the ownership of the file, for example). > > Furthermore, the kernel has completely different checks, although the > comments in lib/libc/posix1e/acl_support.c say: * _posix1e_acl_check -- > given an ACL, check its validity. This is * mirrored from code in > sys/kern/kern_acl.c, and if changes are made in * one, they should be made > in the other also. > > What the kernel does is simply to set the qualifier for ACL_USER_OBJ and > ACL_GROUP_OBJ to ACL_UNDEFINED_ID, which seems sane, and then it checks the > qualifier for ACL_USER to be not equal to UNDEFINED_ID, which is much more > reasonable than the userspace code. > > Do I misunderstand here the usage? Dear Iustin: Sorry about the long delay in replying. I've reviewed POSIX.1e and concur that there's nothing in the spec that seems to prohibit having an ACL_GROUP or ACL_USER entry with a qualifier that matches the file group or file owner. And, in fact, you can construct such a case now on FreeBSD, despite the validity check, by first setting the ACL and then chowning the file to the desired user or group matching an existing entry in the ACL. Looking at the library code, this is indeed a problem, and I'll take a look at fixing this shortly. Is there any chance I could get you to submit a PR on this problem, then forward me the PR receipt so I can grab ownership of it? Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > Sample program: > #include > #include > #include > #include > #include > > int main() { > acl_t ma; > acl_entry_t e; > uid_t user=getuid(); > > ma = acl_from_text("u::rw,g::r,o::-"); > if(ma==NULL) > perror("acl_from_text"); > if(acl_valid(ma)==-1) > perror("initial acl is not valid"); > if(acl_create_entry(&ma, &e)==-1) > perror("acl_create_entry"); > if(acl_set_tag_type(e, ACL_USER)==-1) > perror("acl_set_tag_type"); > if(acl_set_qualifier(e, &user)==-1) > perror("acl_set_qualifier"); > if(acl_calc_mask(&ma)==-1) > perror("acl_calc_mask"); > if(acl_valid(ma)==-1) > perror("modified acl is not valid"); > } > > in this example, the acl_calc_mask and acl_valid will fail unless the > getuid() is changed to getuid()+1. > > thanks, > iustin > _______________________________________________ > posix1e@FreeBSD.org mailing list > http://lists.freebsd.org/mailman/listinfo/posix1e > To unsubscribe, send any mail to "posix1e-unsubscribe@FreeBSD.org" > From owner-posix1e@FreeBSD.ORG Sun Jul 13 16:39:16 2008 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 610481065676 for ; Sun, 13 Jul 2008 16:39:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3597D8FC1F for ; Sun, 13 Jul 2008 16:39:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C036746C31; Sun, 13 Jul 2008 12:39:15 -0400 (EDT) Date: Sun, 13 Jul 2008 17:39:15 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Iustin Pop In-Reply-To: <20080628090524.GA5399@teal.hq.k1024.org> Message-ID: <20080713173851.J9673@fledge.watson.org> References: <20080628090524.GA5399@teal.hq.k1024.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: posix1e@FreeBSD.org Subject: Re: userland acl_valid() wierdness X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2008 16:39:16 -0000 On Sat, 28 Jun 2008, Iustin Pop wrote: > Do I misunderstand here the usage? FYI: rwatson 2008-07-13 16:37:51 UTC FreeBSD src repository Modified files: lib/libc/posix1e acl_support.c Log: SVN rev 180493 on 2008-07-13 16:37:51Z by rwatson The libc acl_valid(3) function validates the contents of a POSIX.1e ACL. This change removes the requirement that an ACL contain no ACL_USER entries with a uid the same as those of a file, or ACL_GROUP entries with a gid the same as those of a file. This requirement is not in the specification, and not enforced by the kernel's ACL implementation. Reported by: Iustin Pop MFC after: 1 week Revision Changes Path 1.15 +2 -8 src/lib/libc/posix1e/acl_support.c From owner-posix1e@FreeBSD.ORG Sun Jul 13 16:51:27 2008 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 362B0106567A for ; Sun, 13 Jul 2008 16:51:27 +0000 (UTC) (envelope-from iusty@k1024.org) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by mx1.freebsd.org (Postfix) with ESMTP id B9B6B8FC1E for ; Sun, 13 Jul 2008 16:51:26 +0000 (UTC) (envelope-from iusty@k1024.org) Received: by fk-out-0910.google.com with SMTP id k31so2539754fkk.11 for ; Sun, 13 Jul 2008 09:51:25 -0700 (PDT) Received: by 10.86.82.16 with SMTP id f16mr13064458fgb.16.1215967884960; Sun, 13 Jul 2008 09:51:24 -0700 (PDT) Received: from teal.hq.k1024.org ( [84.75.130.139]) by mx.google.com with ESMTPS id 12sm6971129fgg.0.2008.07.13.09.51.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Jul 2008 09:51:24 -0700 (PDT) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id EB16B40A07A; Sun, 13 Jul 2008 18:51:22 +0200 (CEST) Date: Sun, 13 Jul 2008 18:51:22 +0200 From: Iustin Pop To: Robert Watson Message-ID: <20080713165122.GA800@teal.hq.k1024.org> References: <20080628090524.GA5399@teal.hq.k1024.org> <20080713173851.J9673@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080713173851.J9673@fledge.watson.org> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.18 (2008-05-17) Cc: posix1e@FreeBSD.org Subject: Re: userland acl_valid() wierdness X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2008 16:51:27 -0000 On Sun, Jul 13, 2008 at 05:39:15PM +0100, Robert Watson wrote: > > On Sat, 28 Jun 2008, Iustin Pop wrote: > >> Do I misunderstand here the usage? > > FYI: > > rwatson 2008-07-13 16:37:51 UTC > > FreeBSD src repository > > Modified files: > lib/libc/posix1e acl_support.c > Log: > SVN rev 180493 on 2008-07-13 16:37:51Z by rwatson [...] Thanks! I just filled PR number 125575 - please note that it's my first PR report, so I might have filled it wrongly, my apologies, and it took a while until I figured it out. It seems you can already close it :) iustin From owner-posix1e@FreeBSD.ORG Sat Sep 6 13:37:16 2008 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3876C106566B for ; Sat, 6 Sep 2008 13:37:16 +0000 (UTC) (envelope-from trasz@FreeBSD.org) Received: from pin.if.uz.zgora.pl (pin.if.uz.zgora.pl [212.109.128.251]) by mx1.freebsd.org (Postfix) with ESMTP id 089528FC15 for ; Sat, 6 Sep 2008 13:37:15 +0000 (UTC) (envelope-from trasz@FreeBSD.org) Received: by pin.if.uz.zgora.pl (Postfix, from userid 1001) id 98FCF39CFB; Sat, 6 Sep 2008 15:25:12 +0200 (CEST) Date: Sat, 6 Sep 2008 15:25:12 +0200 From: Edward Tomasz Napierala To: Pedro Martelletto , posix1e@FreeBSD.org Message-ID: <20080906132512.GA77144@pin.if.uz.zgora.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Sat, 06 Sep 2008 13:42:06 +0000 Cc: Subject: Re: Fix freeing of ACLs in 'setfacl' X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 13:37:16 -0000 ----- Forwarded message from Edward Tomasz Napierala ----- Date: Sat, 6 Sep 2008 13:17:35 +0000 (UTC) Subject: svn commit: r182813 - head/bin/setfacl From: Edward Tomasz Napierala To: src-committers@freebsd.org Author: trasz Date: Sat Sep 6 13:17:35 2008 New Revision: 182813 URL: http://svn.freebsd.org/changeset/base/182813 Log: Fix double free in setfacl(1). Description from the author: Initially, 'acl' (an 'acl_t *') is allocated, and its ACCESS_ACL and DEFAULT_ACL fields are passed to the 'libc' ACL routines for subsequent allocation. If the '-m' option (merge existing ACL with a new one) is specified, then 'set_acl_mask()' will be called and passed one of the two ACLs. This function, in turn, replaces this given ACL structure by another, freshly allocated. However, the pointer in the 'acl' variable in the caller is not updated. The caller then proceeds to free the ACL, incurring in a double free condition. Submitted by: Pedro Martelletto Approved by: rwatson (mentor) Modified: head/bin/setfacl/setfacl.c Modified: head/bin/setfacl/setfacl.c ============================================================================== --- head/bin/setfacl/setfacl.c Sat Sep 6 10:12:52 2008 (r182812) +++ head/bin/setfacl/setfacl.c Sat Sep 6 13:17:35 2008 (r182813) @@ -245,10 +245,13 @@ main(int argc, char *argv[]) continue; } - if (acl_type == ACL_TYPE_ACCESS) + if (acl_type == ACL_TYPE_ACCESS) { final_acl = acl[ACCESS_ACL]; - else + acl_free(acl[DEFAULT_ACL]); + } else { final_acl = acl[DEFAULT_ACL]; + acl_free(acl[ACCESS_ACL]); + } if (need_mask && (set_acl_mask(&final_acl) == -1)) { warnx("failed to set ACL mask on %s", file->filename); @@ -269,8 +272,7 @@ main(int argc, char *argv[]) } } - acl_free(acl[ACCESS_ACL]); - acl_free(acl[DEFAULT_ACL]); + acl_free(final_acl); free(acl); } ----- End forwarded message ----- From owner-posix1e@FreeBSD.ORG Thu Apr 22 22:44:56 2010 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E0671065687 for ; Thu, 22 Apr 2010 22:44:56 +0000 (UTC) (envelope-from eclark@strtrade.com) Received: from dtw-sttasbh02.sttasonline.com (dtwbh02.strtrade.com [69.42.121.220]) by mx1.freebsd.org (Postfix) with ESMTP id 40EC68FC16 for ; Thu, 22 Apr 2010 22:44:53 +0000 (UTC) Received: from dtw-sttasmail03.sttasonline.com ([10.1.20.231]) by dtw-sttasbh02.sttasonline.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 18:32:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Apr 2010 18:23:11 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: POSIX ACL Thread-Index: AcriUXdIrspHjVniTy6Z415w9qHM5wAF8Jyg From: "Erin Clark" To: X-OriginalArrivalTime: 22 Apr 2010 22:32:48.0853 (UTC) FILETIME=[BCB05050:01CAE26B] X-Mailman-Approved-At: Thu, 22 Apr 2010 23:24:17 +0000 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: POSIX ACL X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 22:44:56 -0000 Hi All: =20 I'm assisting a client with the export classification of their product and the subject product utilizes POSIX Access Control Lists 2.2.23. Do you know who might be the correct developer(s) for this open source code? If it's you all, do you happen to know what the Export Control Classification Number (ECCN) for this code? If you don't know the ECCN, can you please respond to the following questions at your convenience? =20 a. Does the code perform cryptographic functions (i.e., encryption/decryption)? b. Does the code contain any cryptographic algorithms (i.e., 3DES, Diffie-Helman, Blowfish, Rijndael, RC4, RSA) (whether or not these algorithms are actually being used by the software)? c. Is the code capable of interfacing with, calling to, using, invoking or enabling/disabling the cryptographic features within other software or within the underlying platform in any way? d. Is the code capable of performing message digesting/hashing (i.e., MD5, RIPEMD, SHA, Tiger), fixed data compression or authentication? e. Does the code contain/utilize and open cryptographic interface (OCI), where the cryptographic capabilities of the code are user-accessible and/or modifiable? (See below for a more detailed definition of OCI.) =20 =20 If 'yes' to any of the above, please provide detailed response. (Open cryptographic interface - A mechanism which is designed to allow a customer or other party to insert cryptographic functionality without the intervention, help or assistance of the manufacturer or its agents (i.e., manufacturer's signing of cryptographic code or proprietary interfaces). If the cryptographic interface implements a fixed set of cryptographic algorithms, key lengths or key exchange management systems, that cannot be changed, it will not be considered an "open" cryptographic interface. All general application programming interfaces (i.e., those that accept either a cryptographic or non-cryptographic interface, but do not themselves maintain any cryptographic functionality) will not be considered "open" cryptographic interfaces either.) Please let me know if you have any questions for me and many thanks in advance for your assistance. =20 Regards, Erin =20 Erin Clark Export Compliance Manager ________________________________ Sandler & Travis Trade Advisory Services, Inc.=20 =20 |phone 248.699.1588 | cell 619.997.4197 | fax 619.330.2336 | Web | eMail | =20 This is a transmission from Sandler & Travis Trade Advisory Services, Inc. and is solely for the use of the intended addressee. It may contain information which is confidential and subject to attorney client privilege. If you are not the intended recipient, please e-mail the sender and destroy all copies of this message and any attachment. Any unauthorized use of the contents of the message or attachments is strictly prohibited. =20 P PLEASE CONSIDER THE ENVIRONMENT BEFORE PRINTING =20 From owner-posix1e@FreeBSD.ORG Fri Apr 23 02:21:07 2010 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99D3E1065672 for ; Fri, 23 Apr 2010 02:21:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 75D218FC17 for ; Fri, 23 Apr 2010 02:21:07 +0000 (UTC) Received: from [192.168.0.2] (unknown [12.104.12.83]) by cyrus.watson.org (Postfix) with ESMTPSA id 9439546B65; Thu, 22 Apr 2010 22:21:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Thu, 22 Apr 2010 22:20:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <44824700-ECA8-4560-9F03-69B9F29176D7@FreeBSD.org> References: To: "Erin Clark" X-Mailer: Apple Mail (2.1078) Cc: posix1e@FreeBSD.org Subject: Re: POSIX ACL X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 02:21:07 -0000 On 22 Apr 2010, at 18:23, Erin Clark wrote: > I'm assisting a client with the export classification of their product > and the subject product utilizes POSIX Access Control Lists 2.2.23. = Do > you know who might be the correct developer(s) for this open source > code? If it's you all, do you happen to know what the Export Control > Classification Number (ECCN) for this code? If you don't know the = ECCN, > can you please respond to the following questions at your convenience? Hi Erin-- The answers to these questions will be specific to the product you are = considering, open source or otherwise. If you could let us know what = specific software you're looking at, perhaps we could point you in the = right direction (for example, is it FreeBSD?). However, in the general = case, POSIX.1e ACLs are a local file system access control mechanism = unrelated to cryptography, and are therefore unlikely to involve = cryptography in their implementation. Robert= From owner-posix1e@FreeBSD.ORG Fri Apr 23 15:44:49 2010 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A10431065672 for ; Fri, 23 Apr 2010 15:44:49 +0000 (UTC) (envelope-from eclark@strtrade.com) Received: from dtw-sttasbh02.sttasonline.com (dtwbh02.strtrade.com [69.42.121.220]) by mx1.freebsd.org (Postfix) with ESMTP id 49B5F8FC29 for ; Fri, 23 Apr 2010 15:44:48 +0000 (UTC) Received: from dtw-sttasmail03.sttasonline.com ([10.1.20.231]) by dtw-sttasbh02.sttasonline.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Apr 2010 11:44:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Apr 2010 11:44:18 -0400 Message-ID: In-Reply-To: <44824700-ECA8-4560-9F03-69B9F29176D7@FreeBSD.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: POSIX ACL Thread-Index: Acrii6LRP3FTQGqJTdCH4odCeJRkxwAbwUUw References: <44824700-ECA8-4560-9F03-69B9F29176D7@FreeBSD.org> From: "Erin Clark" To: "Robert N. M. Watson" X-OriginalArrivalTime: 23 Apr 2010 15:44:47.0331 (UTC) FILETIME=[E6FA4330:01CAE2FB] X-Mailman-Approved-At: Fri, 23 Apr 2010 16:10:02 +0000 Cc: posix1e@FreeBSD.org Subject: RE: POSIX ACL X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 15:44:49 -0000 Hi Robert: Thanks so much for your response. Unfortunately, I don't know what the specific product is . . . However, below is the description that I do have: "POSIX Access Control Lists -- used to define more fine-grained discretionary access rights for files and directories." Given that POSIX ACLs are an access control mechanism, do they contain any algorithms that perform authentication/password protection? Thanks, Erin -----Original Message----- From: Robert N. M. Watson [mailto:rwatson@FreeBSD.org]=20 Sent: Thursday, April 22, 2010 7:21 PM To: Erin Clark Cc: posix1e@FreeBSD.org Subject: Re: POSIX ACL On 22 Apr 2010, at 18:23, Erin Clark wrote: > I'm assisting a client with the export classification of their product > and the subject product utilizes POSIX Access Control Lists 2.2.23. Do > you know who might be the correct developer(s) for this open source > code? If it's you all, do you happen to know what the Export Control > Classification Number (ECCN) for this code? If you don't know the ECCN, > can you please respond to the following questions at your convenience? Hi Erin-- The answers to these questions will be specific to the product you are considering, open source or otherwise. If you could let us know what specific software you're looking at, perhaps we could point you in the right direction (for example, is it FreeBSD?). However, in the general case, POSIX.1e ACLs are a local file system access control mechanism unrelated to cryptography, and are therefore unlikely to involve cryptography in their implementation. Robert From owner-posix1e@FreeBSD.ORG Fri Apr 23 16:49:04 2010 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4CF5106566B; Fri, 23 Apr 2010 16:49:04 +0000 (UTC) (envelope-from jonathan.leffler@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id 599E68FC12; Fri, 23 Apr 2010 16:49:04 +0000 (UTC) Received: by iwn42 with SMTP id 42so5884649iwn.14 for ; Fri, 23 Apr 2010 09:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=3S0ot7hcmO3nnzmmYcCIZFhDjO8C+wuUZrSfsrhk5fM=; b=qsTbA50q6850bd0HhMuQtAKqWmZp5Vm8Ovkw62+3TlmeuvvUwMVwuExVC6GRzbCfIK EUifmeLngp0R5I6+rdbKwBCUyMfZABwLGiL/BBzFha6vVhmUPlZbVcQBjmrPh6PrgNiU +GHQypCRvb02rSv6qDgiHQlg5FP1S9jBYYwho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=uqijmJYI2JcDTS9LEPoqtl3w0efmzNCqbbmj37L0kEOoMXbJ3ZPIZuQ3D8XZrfnsQA sgE+j1U+sDc0u7JapAjEEUeY08ST6ZFBT9maDUmsgvEO96su3teIOCyXaXeH3CFqj8yx pHfQDza1cSoZ0OxZYoMmVtl5+5hWECjyDXj38= Received: by 10.231.153.149 with SMTP id k21mr76199ibw.17.1272039488770; Fri, 23 Apr 2010 09:18:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.204 with HTTP; Fri, 23 Apr 2010 09:17:48 -0700 (PDT) In-Reply-To: References: <44824700-ECA8-4560-9F03-69B9F29176D7@FreeBSD.org> From: Jonathan Leffler Date: Fri, 23 Apr 2010 09:17:48 -0700 Message-ID: To: Erin Clark Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: posix1e@freebsd.org Subject: Re: POSIX ACL X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 16:49:04 -0000 On Fri, Apr 23, 2010 at 8:44 AM, Erin Clark wrote: > Thanks so much for your response. Unfortunately, I don't know what the > specific product is . . . However, below is the description that I do > have: > > "POSIX Access Control Lists -- used to define more fine-grained > discretionary access rights for files and directories." > > Given that POSIX ACLs are an access control mechanism, do they contain > any algorithms that perform authentication/password protection? > No - the ACLs are applied after authentication and identification is complete. They authorize the use of resources by the 'person' (meaning process) that is attempting to access them. > -----Original Message----- > From: Robert N. M. Watson [mailto:rwatson@FreeBSD.org] > Sent: Thursday, April 22, 2010 7:21 PM > > On 22 Apr 2010, at 18:23, Erin Clark wrote: > > > I'm assisting a client with the export classification of their product > > and the subject product utilizes POSIX Access Control Lists 2.2.23. > Do > > you know who might be the correct developer(s) for this open source > > code? If it's you all, do you happen to know what the Export Control > > Classification Number (ECCN) for this code? If you don't know the > ECCN, > > can you please respond to the following questions at your convenience? > > Hi Erin-- > > The answers to these questions will be specific to the product you are > considering, open source or otherwise. If you could let us know what > specific software you're looking at, perhaps we could point you in the > right direction (for example, is it FreeBSD?). However, in the general > case, POSIX.1e ACLs are a local file system access control mechanism > unrelated to cryptography, and are therefore unlikely to involve > cryptography in their implementation. > Resent to list too... -- Jonathan Leffler #include Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." From owner-posix1e@FreeBSD.ORG Fri Apr 23 17:20:04 2010 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54D401065672; Fri, 23 Apr 2010 17:20:04 +0000 (UTC) (envelope-from eclark@strtrade.com) Received: from dtw-sttasbh02.sttasonline.com (dtwbh02.strtrade.com [69.42.121.220]) by mx1.freebsd.org (Postfix) with ESMTP id E334D8FC14; Fri, 23 Apr 2010 17:20:03 +0000 (UTC) Received: from dtw-sttasmail03.sttasonline.com ([10.1.20.231]) by dtw-sttasbh02.sttasonline.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Apr 2010 13:20:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Apr 2010 13:19:58 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: POSIX ACL Thread-Index: AcrjAJFetfNlD8jFQv2YQ6R9lMRCKgACIwMg References: <44824700-ECA8-4560-9F03-69B9F29176D7@FreeBSD.org> From: "Erin Clark" To: "Jonathan Leffler" X-OriginalArrivalTime: 23 Apr 2010 17:20:02.0222 (UTC) FILETIME=[35516CE0:01CAE309] X-Mailman-Approved-At: Fri, 23 Apr 2010 18:03:10 +0000 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: posix1e@freebsd.org Subject: RE: POSIX ACL X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 17:20:04 -0000 Thank you very much! =20 Have a great weekend. =20 Best regards, Erin =20 From: Jonathan Leffler [mailto:jonathan.leffler@gmail.com]=20 Sent: Friday, April 23, 2010 9:18 AM To: Erin Clark Cc: Robert N. M. Watson; posix1e@freebsd.org Subject: Re: POSIX ACL =20 =20 On Fri, Apr 23, 2010 at 8:44 AM, Erin Clark wrote: Thanks so much for your response. Unfortunately, I don't know what the specific product is . . . However, below is the description that I do have: "POSIX Access Control Lists -- used to define more fine-grained discretionary access rights for files and directories." Given that POSIX ACLs are an access control mechanism, do they contain any algorithms that perform authentication/password protection? No - the ACLs are applied after authentication and identification is complete. They authorize the use of resources by the 'person' (meaning process) that is attempting to access them. =20 -----Original Message----- From: Robert N. M. Watson [mailto:rwatson@FreeBSD.org] Sent: Thursday, April 22, 2010 7:21 PM =09 On 22 Apr 2010, at 18:23, Erin Clark wrote: =09 > I'm assisting a client with the export classification of their product > and the subject product utilizes POSIX Access Control Lists 2.2.23. Do > you know who might be the correct developer(s) for this open source > code? If it's you all, do you happen to know what the Export Control > Classification Number (ECCN) for this code? If you don't know the ECCN, > can you please respond to the following questions at your convenience? =09 Hi Erin-- =09 The answers to these questions will be specific to the product you are considering, open source or otherwise. If you could let us know what specific software you're looking at, perhaps we could point you in the right direction (for example, is it FreeBSD?). However, in the general case, POSIX.1e ACLs are a local file system access control mechanism unrelated to cryptography, and are therefore unlikely to involve cryptography in their implementation. Resent to list too... --=20 Jonathan Leffler #include Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." From owner-posix1e@FreeBSD.ORG Wed Nov 6 15:30:59 2013 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 82DFDE4F; Wed, 6 Nov 2013 15:30:59 +0000 (UTC) (envelope-from kientzle@acm.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3493327A4; Wed, 6 Nov 2013 15:30:55 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id rA6FUjrm008430; Wed, 6 Nov 2013 15:30:45 GMT (envelope-from kientzle@acm.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 67536k45mncdh9g2ps7ydyw66a; Wed, 06 Nov 2013 15:30:45 +0000 (UTC) (envelope-from kientzle@acm.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Subject: Re: NFSv4 ACL support in star From: Tim Kientzle In-Reply-To: <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> Date: Wed, 6 Nov 2013 07:30:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg Schilling X-Mailer: Apple Mail (2.1816) X-Mailman-Approved-At: Wed, 06 Nov 2013 18:07:48 +0000 Cc: star-developers@lists.berlios.de, Pavel Raiskup , Richard Yao , posix1e@FreeBSD.org, Pawel Jakub Dawidek , behlendorf1@llnl.gov X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 15:30:59 -0000 CC: rwatson@ who implemented FreeBSD=92s POSIX.1e ACL implementation CC: trasz@ who implemented FreeBSD=92s NFSv4 ACL implementation CC: posix1e@freebsd.org, which has a number of security-minded people who might have suggestions here. On Nov 5, 2013, at 6:51 AM, Joerg Schilling = wrote: > Richard Yao wrote: >=20 >>> BTW: I expect a local ACL implementation (as Solaris does) to be = able to >>> auto-convert POSIX draft ACLs into NFSv4 ACLs and it would be nice = if we >>> did find a way to do the converse soon. >>=20 >> The converse is widely considered to be impossible: >>=20 >> "Since NFSv4 ACLs are more fine-grained than POSIX ACLs, it is not >> possible in general to map an arbitrary NFSv4 ACL to a POSIX ACL with >> the same semantics." >=20 > Well, I know that one reason for withdrawing the POSIX ACL draft in = October=20 > 1997 was that the POSIX draft was too simple and did not implement = what people=20 > like to see. >=20 > I am still wondering whether it is possible to implement an = aproximation that=20 > could be better than not having a reverse conversion at all. I worry that approximation could be much worse than having no conversion = at all. ACL conversions can create hidden latent security problems. At a minimum, any ACL conversion should produce obvious warnings. I=92ve seen security experts worry even about conversions between NFSv4 and NTFS ACLs (which are almost identical). That said, having good default translations from POSIX.1e to NFSv4 ACLs seems a necessity to help people migrate. But the reverse conversion seems very risky to me. > I would expect that an NFSv4 ACL that does not make use from deny type = entries=20 > and that does not use the other permissions from NFSv4 ACLs should = have a good=20 > chance for a not too bad conversion. Maybe this kind of conversion = could be=20 > made optional via a star command line switch=85. In addition to deny entries, NFSv4 ACLs also support ACL inheritance controls that are critical to preserving ACL intent and which cannot be represented in POSIX.1e. >=20 >> http://tools.ietf.org/id/draft-ietf-nfsv4-acl-mapping-03.txt >>=20 >> This did not stop the Linux NFSv4 server from doing it. To my = knowledge, >> the Linux NFSv4 implementation does not properly preserve the = semantics. Doing ACL conversion automatically at the filesystem or system call/libc layer is a really bad idea. Doing it in backup/restore utilities such as tar may be necessary to assist people in migrating. Library support for that would certainly help. >> i.e. There are situations where the NFSv4 ACLs that you get back from >> the Linux NFSv4 server do not match what you set. I=92m not familiar with the Linux NFSv4 server: Are there cases where the ACLs that you set are not the ACLs that actually get enforced? That would be very, very bad. > I was asking in hope to get knowledge whether there is a free = implementation=20 > for this kind of conversion. >=20 >>> I selected ACL_COMPACT_FMT as it tends to create slightly shorter = strings. >>>=20 >>> Are there any objections or forseeable problems for the future? >>=20 >> You might want to read the link that I provided above. >=20 > Did you see problems mentioned in that ietf paper? > I just die a coarse read during last weekend so far... >=20 >=20 >> I don't know of any library that does what you want. There was an >> extension of NFSv4 ACLs called Richacls that attempted two combine = the >> two ACL implementations. However, conversion only worked one way: >>=20 >> http://www.bestbits.at/richacl/ >>=20 >> With that being said, you will likely need to handle NFSv4 ACLs and >> POSIX ACLs independently. Since only 1 ACL implementation is active = at a >> time, you could probably have a bit to indicate which of the two is = used. Yes. All of the tar ACL extensions currently store a single type of ACL and mark which kind it is. Hopefully, none of them will be silly enough to write a translated ACL into an archive. (Someone will think of it; worse, someone will suggest storing both the original and the translated version. Ugh.) > Are you talking about Linux here? >=20 > Given the fact that FreeBSD and Linux did implement a sufficiently = identical=20 > library for POSIX draft ACLs in the past, I am in hope, we could = arrange the=20 > same for NFSv4 ACLs. So it would be nice if platforms besides Solaris = did=20 > either pick up the libsec interface for both POSIX draft ACLs and = NFSv4 ACLs or=20 > implement a compatible enhenced version of their previous POSIX draft = ACL=20 > library. >=20 > BTW: I tried to contact Andreas before but did not get a reply yet. >=20 > For the POSIX draft -> NFSv4 conversion, people could use the code = from=20 > OpenSolaris libsec: >=20 >=20 > = http://hg.berlios.de/repos/schillix-on/file/2f5a0fb0368d/usr/src/lib/libse= c Thanks for that pointer. We should all certainly take a look at that. Having consistent translations on multiple platforms would certainly help. Cheers, Tim From owner-posix1e@FreeBSD.ORG Wed Nov 6 17:40:09 2013 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ABA9B5D5 for ; Wed, 6 Nov 2013 17:40:09 +0000 (UTC) (envelope-from joerg.schilling@fokus.fraunhofer.de) Received: from mx-relay02-dus.antispameurope.com (mx-relay02-dus.antispameurope.com [94.100.134.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 07F872F52 for ; Wed, 6 Nov 2013 17:40:05 +0000 (UTC) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by mx-gate02-dus.antispameurope.com; Wed, 06 Nov 2013 18:39:46 +0100 Received: from CURIE.fokus.fraunhofer.de (curie.fokus.fraunhofer.de [10.147.9.203]) by pluto.fokus.fraunhofer.de (8.14.4/8.14.2) with ESMTP id rA6HdgsX005108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 Nov 2013 18:39:42 +0100 (CET) Received: from rigel (10.147.13.100) by CURIE.fokus.fraunhofer.de (10.147.9.203) with Microsoft SMTP Server id 14.3.158.1; Wed, 6 Nov 2013 18:39:41 +0100 Date: Wed, 6 Nov 2013 18:39:41 +0100 From: Joerg Schilling To: Subject: Re: NFSv4 ACL support in star Message-ID: <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-KSE-Antivirus-Interceptor-Info: protection disabled X-cloud-security-sender: joerg.schilling@fokus.fraunhofer.de X-cloud-security-recipient: posix1e@freebsd.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate02-dus with 5C0A63880009 X-cloud-security-connect: pluto.fokus.fraunhofer.de[195.37.77.164], TLS=, IP=195.37.77.164 X-cloud-security: scantime:.2657 X-Mailman-Approved-At: Wed, 06 Nov 2013 18:32:22 +0000 Cc: star-developers@lists.berlios.de, praiskup@redhat.com, ryao@gentoo.org, ag@bestbits.at, posix1e@FreeBSD.org, pjd@FreeBSD.org, behlendorf1@llnl.gov X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:40:09 -0000 Trying to add Andreas Grünbacher who implemented the original POSIX.1e code for Linux. Tim Kientzle wrote: > CC: rwatson@ who implemented FreeBSD?s POSIX.1e ACL implementation > > CC: trasz@ who implemented FreeBSD?s NFSv4 ACL implementation > > CC: posix1e@freebsd.org, which has a number of security-minded > people who might have suggestions here. Thank you for adding these people. There is a need to come to an implementation that is useful for tar and I had already bad experiences with Sun/Solaris: - In 2005, Sun made the same mistake in the NFSv4 ACL implemenation as they did in 1993 for the UFS ACLs: They did not add the numerical ID in the text. Well, they added this later to libsec (and introduced ACL_APPEND_ID). - Some of the important interfaces from libsec are missing from sys/acl.h and only available to code that sits inside the Solaris source code and thus is able to #include . These interfaces include: acl_type() that allows to find the ACL type in use behind the acl_t variable. acl_strerror() that allows to translate ACL errors into text. I like to see an implementation that (if implemented as an enhancement of the withdrawn POSIX.1e ACL interfaces) gives similar features as libsec does: - libsec e.g. calls pathconf(name, _PC_ACL_ENABLED) in order to find the ACL type that is used for a file and controls which ACL flavor to retrieve. - libsec includes code to deal with ephemeral IDs used with CIFS clients. - libsec offers acl_type(aclp) to find the ACl type without a need to call acl_totext(), so I could use: acl_totext(aclp, 0) for UFS ACLs and the known to work postprocess code. or acl_totext(aclp, ACL_COMPACT_FMT | ACL_APPEND_ID | ACL_SID_FMT) for NFSv4 ACLS. See e.g.: http://schillix.berlios.de/man/man3sec/acl_totext.3sec.html and other man pages at: http://schillix.berlios.de/man/man3sec/ I am in hope that we could get a final library interface that still stays compatible between FreeBSD and Linux as this was the base for being able to support more platforms with POSIX.1e draft ACLs. > > I am still wondering whether it is possible to implement an aproximation that > > could be better than not having a reverse conversion at all. > > I worry that approximation could be much worse than having no conversion at all. I could think about a NFSv4 -> POSIX.1e draft conversion that only converts entries in the form: user:lisa:rwx-----------:-------:allow:502 as this is what you could definitely convert correctly. > ACL conversions can create hidden latent security problems. Such problems exist even if you use Win-DOS based CIFS clients as these clients sometimes reorder NFSv4 ACLs and thus cause a different behavior. > At a minimum, any ACL conversion should produce obvious warnings. > > I?ve seen security experts worry even about conversions between > NFSv4 and NTFS ACLs (which are almost identical). See above, this has been discussed in the opensolaris mailing lists many years ago. The problems that have been discussed have been caused by reordering in a way that even violates the Microsoft documentation. > That said, having good default translations from POSIX.1e > to NFSv4 ACLs seems a necessity to help people migrate. > But the reverse conversion seems very risky to me. This is what I like to see, as I expect many people to migrate in the future. > In addition to deny entries, NFSv4 ACLs also support ACL > inheritance controls that are critical to preserving ACL > intent and which cannot be represented in POSIX.1e. Well, it seems that many people do not think about such problems as e.g. Solaris tar does not touch ACLs that might have been created via inheritance rules in case the related file does not include an own ACL entry in the archive. >From my view, Solaris tar thus is a security risk. > >> http://tools.ietf.org/id/draft-ietf-nfsv4-acl-mapping-03.txt > >> > >> This did not stop the Linux NFSv4 server from doing it. To my knowledge, > >> the Linux NFSv4 implementation does not properly preserve the semantics. > > Doing ACL conversion automatically at the filesystem or system call/libc > layer is a really bad idea. > > Doing it in backup/restore utilities such as tar may be necessary > to assist people in migrating. Library support for that would certainly > help. Maybe the reason is that e.g. Linux did add POSIX.1e draft ACL support in 2001 and NFSv4 ACLs did become the first approved platform spanning ACL standard in y2000 already. On Solaris there was no problem with switching to a new ACL implementation when ZFS was introduced in y2005 to the public. The old UFS ACLs have been in use since 12 years already and people did know that they do not give you what you like. On Linux, someone would have to decide to withdraw a recent implementation immediately after it was introduced.... > I?m not familiar with the Linux NFSv4 server: Are there > cases where the ACLs that you set are not the ACLs that > actually get enforced? That would be very, very bad. On Solaris, the NFSv4 server does not expose ACLs unless the underlying filesystem implements NFSv4 ACLs. > >> With that being said, you will likely need to handle NFSv4 ACLs and > >> POSIX ACLs independently. Since only 1 ACL implementation is active at a > >> time, you could probably have a bit to indicate which of the two is used. > > Yes. All of the tar ACL extensions currently store a single type > of ACL and mark which kind it is. This is why star adds SCHILY.acl.ace= entries for NFSv4 ACLs. I am ready with the final conversions that hopefully will allow the code to compile again on Linux tomorrow. Maybe, I should publish the source then as a base for future discussions. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-posix1e@FreeBSD.ORG Wed Nov 6 19:35:03 2013 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BE267AA5; Wed, 6 Nov 2013 19:35:03 +0000 (UTC) (envelope-from kientzle@acm.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9403627D9; Wed, 6 Nov 2013 19:35:03 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id rA6JYkGg010158; Wed, 6 Nov 2013 19:34:46 GMT (envelope-from kientzle@acm.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id cpkuu44cvgc6jscxc656mhz5qa; Wed, 06 Nov 2013 19:34:46 +0000 (UTC) (envelope-from kientzle@acm.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Subject: Re: NFSv4 ACL support in star From: Tim Kientzle In-Reply-To: <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> Date: Wed, 6 Nov 2013 11:34:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg Schilling X-Mailer: Apple Mail (2.1816) X-Mailman-Approved-At: Wed, 06 Nov 2013 20:36:15 +0000 Cc: star-developers@lists.berlios.de, Pavel Raiskup , Richard Yao , ag@bestbits.at, posix1e@FreeBSD.org, Pawel Jakub Dawidek , behlendorf1@llnl.gov X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:35:03 -0000 On Nov 6, 2013, at 9:39 AM, Joerg Schilling = wrote: > I am ready with the final conversions that hopefully will allow the = code to=20 > compile again on Linux tomorrow. Maybe, I should publish the source = then as a=20 > base for future discussions. Please post some sample archives created with your extensions. I started to add NFSv4 support to libarchive a few years ago but never finished. It would be good to complete that in a way that was compatible. Cheers, Tim From owner-posix1e@FreeBSD.ORG Wed Nov 6 19:49:52 2013 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E2CCF965; Wed, 6 Nov 2013 19:49:51 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 27EEB28F4; Wed, 6 Nov 2013 19:49:51 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id m14so1741394eaj.21 for ; Wed, 06 Nov 2013 11:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vAAm6tgbJ1d2FWSfbe0BDlfR2JdGl431hgs8OrKXy90=; b=myRglevhJyOKnM/grRevFZ4HY6L6whvi9lp4wd7catWfg0g0f2BwNwDGe8hbe9wy3S j9wo4ybKjyNGyhIKc77nwucW8Sn0lCVdLk8HRtpEtoUdaTfNXJci3Nq3L4S9bCaxVDxn Gt/kwn6CzqposhqNpynC1DH375U13z2HuAk9TyLG7pGWjYGeF0CY9ShUTqOswZdYKhRO KLh3PoxNDxZLysXeXOtN+yLrNVDbGsItMebk0FDsuYnO6EN0gA3iylzHa1jjNmeDJCzq cOhbXyGMV8O0Dyk5iG4nYXHiRlBbo45L9BHQ6K8oQEx8hxPAuL6l7KqHM5e2KoiYyfH9 RFwg== X-Received: by 10.14.104.5 with SMTP id h5mr5718032eeg.58.1383767389398; Wed, 06 Nov 2013 11:49:49 -0800 (PST) Received: from [192.168.1.102] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPSA id a6sm77700003eei.10.2013.11.06.11.49.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 11:49:48 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: NFSv4 ACL support in star Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> Date: Wed, 6 Nov 2013 20:49:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5AB09353-50C8-4909-8CEB-27E2DA722C7E@FreeBSD.org> References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg Schilling X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Wed, 06 Nov 2013 22:27:56 +0000 Cc: star-developers@lists.berlios.de, praiskup@redhat.com, ryao@gentoo.org, ag@bestbits.at, posix1e@FreeBSD.org, pjd@FreeBSD.org, behlendorf1@llnl.gov, kientzle@acm.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:49:52 -0000 Wiadomo=B6=E6 napisana przez Joerg Schilling w dniu 6 lis 2013, o godz. = 18:39: > Trying to add Andreas Gr=FCnbacher who implemented the original=20 > POSIX.1e code for Linux. [..] > I like to see an implementation that (if implemented as an enhancement = of the > withdrawn POSIX.1e ACL interfaces) gives similar features as libsec = does: In order to make FreeBSD support NFSv4, I did exactly that: I've added a number of functions, such as acl_get_entry_type_np(3) (basically, this is for "allow/deny" part of ACL), and extended existing ones, e.g. to = add new permissions. > - libsec e.g. calls pathconf(name, _PC_ACL_ENABLED) in order to = find > the ACL type that is used for a file and controls which ACL = flavor to=20 > retrieve. Use the usual pathconf(3), with _PC_ACL_NFS4. > - libsec includes code to deal with ephemeral IDs used with CIFS = clients. Hm, isn't this independent from ACL implementation? > - libsec offers acl_type(aclp) to find the ACl type without a need = to > call acl_totext(), so I could use: See acl_get_brand_np(). > acl_totext(aclp, 0) for UFS ACLs and the known to work = postprocess code. >=20 > or >=20 > acl_totext(aclp, ACL_COMPACT_FMT | ACL_APPEND_ID | ACL_SID_FMT) = for > NFSv4 ACLS. The acl_to_text() function works for both POSIX.1e and NFSv4 ACLs; to = change the output format there is acl_to_text_np(). > See e.g.: http://schillix.berlios.de/man/man3sec/acl_totext.3sec.html > and other man pages at:=20 >=20 > http://schillix.berlios.de/man/man3sec/ >=20 > I am in hope that we could get a final library interface that still = stays=20 > compatible between FreeBSD and Linux as this was the base for being = able to=20 > support more platforms with POSIX.1e draft ACLs. I think porting what I did would be a good choice - it's fully backwards compatible, API-wise, and not actually hacky. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-posix1e@FreeBSD.ORG Thu Nov 7 10:51:06 2013 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8DDEB9D9 for ; Thu, 7 Nov 2013 10:51:06 +0000 (UTC) (envelope-from joerg.schilling@fokus.fraunhofer.de) Received: from mx-relay13-dus.antispameurope.com (mx-relay13-dus.antispameurope.com [94.100.134.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC69421E3 for ; Thu, 7 Nov 2013 10:51:05 +0000 (UTC) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by mx-gate13-dus.antispameurope.com; Thu, 07 Nov 2013 11:50:16 +0100 Received: from DIRAC.fokus.fraunhofer.de (dirac.fokus.fraunhofer.de [10.147.9.201]) by pluto.fokus.fraunhofer.de (8.14.4/8.14.2) with ESMTP id rA7Ao3jn002599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Nov 2013 11:50:03 +0100 (CET) Received: from rigel (10.147.13.100) by DIRAC.fokus.fraunhofer.de (10.147.9.201) with Microsoft SMTP Server id 14.3.158.1; Thu, 7 Nov 2013 11:50:01 +0100 Date: Thu, 7 Nov 2013 11:50:02 +0100 From: Joerg Schilling To: Subject: Re: NFSv4 ACL support in star Message-ID: <527b705a.j9fXX2oQrvuDmZ2X%Joerg.Schilling@fokus.fraunhofer.de> References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-KSE-Antivirus-Interceptor-Info: protection disabled X-cloud-security-sender: joerg.schilling@fokus.fraunhofer.de X-cloud-security-recipient: posix1e@freebsd.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate13-dus with 98C34211800A X-cloud-security-connect: pluto.fokus.fraunhofer.de[195.37.77.164], TLS=, IP=195.37.77.164 X-cloud-security: scantime:1.058 X-Mailman-Approved-At: Thu, 07 Nov 2013 13:42:00 +0000 Cc: star-developers@lists.berlios.de, posix1e@FreeBSD.org, ryao@gentoo.org, ag@bestbits.at, praiskup@redhat.com, pjd@FreeBSD.org, behlendorf1@llnl.gov X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 10:51:06 -0000 Tim Kientzle wrote: > > On Nov 6, 2013, at 9:39 AM, Joerg Schilling wrote: > > > I am ready with the final conversions that hopefully will allow the code to > > compile again on Linux tomorrow. Maybe, I should publish the source then as a > > base for future discussions. > > Please post some sample archives created with your extensions. I created an updated man page at: http://cdrecord.berlios.de/private/man/star/star.4.html give me some time to create some archives. > I started to add NFSv4 support to libarchive a few years ago > but never finished. It would be good to complete that in a way > that was compatible. I was going to implement NFSv4 support in 2005, but then it took a lot of time to convince Sun to implement a useful library interface. There have been problems in both acltotext() and aclfromtex() and after some time, Sun finally came up with acl_totext() and acl_fromtex() but then I had no time and the project went out of my mind. BTW: when this is done, it may make sense to discuss a portable format for extended attribute files that are also defined by NFSv4 and ZFS. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-posix1e@FreeBSD.ORG Thu Nov 7 11:12:07 2013 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 23127689 for ; Thu, 7 Nov 2013 11:12:07 +0000 (UTC) (envelope-from joerg.schilling@fokus.fraunhofer.de) Received: from mx-relay03-dus.antispameurope.com (mx-relay03-dus.antispameurope.com [94.100.134.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 84B4423AE for ; Thu, 7 Nov 2013 11:12:06 +0000 (UTC) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by mx-gate03-dus.antispameurope.com; Thu, 07 Nov 2013 12:11:03 +0100 Received: from FEYNMAN.fokus.fraunhofer.de (feynman.fokus.fraunhofer.de [10.147.9.202]) by pluto.fokus.fraunhofer.de (8.14.4/8.14.2) with ESMTP id rA7BAex2003710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Nov 2013 12:10:40 +0100 (CET) Received: from rigel (10.147.13.100) by FEYNMAN.fokus.fraunhofer.de (10.147.9.202) with Microsoft SMTP Server id 14.3.158.1; Thu, 7 Nov 2013 12:10:40 +0100 Date: Thu, 7 Nov 2013 12:10:39 +0100 From: Joerg Schilling To: Subject: Re: NFSv4 ACL support in star Message-ID: <527b752f.5Y++ut7T0v9V9Hs6%Joerg.Schilling@fokus.fraunhofer.de> References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> <5AB09353-50C8-4909-8CEB-27E2DA722C7E@FreeBSD.org> In-Reply-To: <5AB09353-50C8-4909-8CEB-27E2DA722C7E@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-KSE-Antivirus-Interceptor-Info: protection disabled X-cloud-security-sender: joerg.schilling@fokus.fraunhofer.de X-cloud-security-recipient: posix1e@freebsd.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate03-dus with 02AC93880050 X-cloud-security-connect: pluto.fokus.fraunhofer.de[195.37.77.164], TLS=, IP=195.37.77.164 X-cloud-security: scantime:1.603 X-Mailman-Approved-At: Thu, 07 Nov 2013 13:42:10 +0000 Cc: star-developers@lists.berlios.de, posix1e@FreeBSD.org, ryao@gentoo.org, ag@bestbits.at, praiskup@redhat.com, pjd@FreeBSD.org, behlendorf1@llnl.gov, kientzle@acm.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 11:12:07 -0000 Edward Tomasz Napiera?a wrote: > > I like to see an implementation that (if implemented as an enhancement of the > > withdrawn POSIX.1e ACL interfaces) gives similar features as libsec does: > > In order to make FreeBSD support NFSv4, I did exactly that: I've added > a number of functions, such as acl_get_entry_type_np(3) (basically, this > is for "allow/deny" part of ACL), and extended existing ones, e.g. to add > new permissions. This looks like a missunderstanding: I am not interested in single entries but in the currnt state of the acl_t object. acl_type(aclp) returns: ACLENT_T = 0, UFS ACLs (compatible with POSIX draft) ACE_T = 1 NFSv4 ACLs I need to know whether to create SCHILX.acl.access and SCHILY.acl.default keywords or SCHILY.acl.ace before I convert things and I don't like to parse the text... > > - libsec e.g. calls pathconf(name, _PC_ACL_ENABLED) in order to find > > the ACL type that is used for a file and controls which ACL flavor to > > retrieve. > > Use the usual pathconf(3), with _PC_ACL_NFS4. This looks like an interface that is not optimized for performance. pathconf(name, _PC_ACL_ENABLED) returns _ACL_ACLENT_ENABLED (1) if the filesystem supports UFS ACLs _ACL_ACE_ENABLED (2) if the filesystem supportfs NFSv4 ACLs or a bitwise or of both. But if you implement another performant method I am OK. > > - libsec includes code to deal with ephemeral IDs used with CIFS clients. > > Hm, isn't this independent from ACL implementation? It may look so but there are related ACE entries and these ACEs carry ephemeral UID/GID values. > > - libsec offers acl_type(aclp) to find the ACl type without a need to > > call acl_totext(), so I could use: > > See acl_get_brand_np(). OK, this is what I am interested in. > > I am in hope that we could get a final library interface that still stays > > compatible between FreeBSD and Linux as this was the base for being able to > > support more platforms with POSIX.1e draft ACLs. > > I think porting what I did would be a good choice - it's fully backwards > compatible, API-wise, and not actually hacky. Well, it would be nice to see feedback from Linux people. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-posix1e@FreeBSD.ORG Thu Nov 7 14:22:55 2013 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2D4544C7; Thu, 7 Nov 2013 14:22:55 +0000 (UTC) (envelope-from kientzle@acm.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 02CAA23A7; Thu, 7 Nov 2013 14:22:53 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id rA7EMiX1015957; Thu, 7 Nov 2013 14:22:44 GMT (envelope-from kientzle@acm.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id niriaiy73pwajehxx2djdxv3ve; Thu, 07 Nov 2013 14:22:43 +0000 (UTC) (envelope-from kientzle@acm.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Subject: Re: NFSv4 ACL support in star From: Tim Kientzle In-Reply-To: <527b752f.5Y++ut7T0v9V9Hs6%Joerg.Schilling@fokus.fraunhofer.de> Date: Thu, 7 Nov 2013 06:22:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> <5AB09353-50C8-4909-8CEB-27E2DA722C7E@FreeBSD.org> <527b752f.5Y++ut7T0v9V9Hs6%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg Schilling X-Mailer: Apple Mail (2.1816) X-Mailman-Approved-At: Thu, 07 Nov 2013 18:27:09 +0000 Cc: star-developers@lists.berlios.de, posix1e@FreeBSD.org, Richard Yao , ag@bestbits.at, Pavel Raiskup , Pawel Jakub Dawidek , behlendorf1@llnl.gov X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:22:55 -0000 On Nov 7, 2013, at 3:10 AM, Joerg Schilling = wrote: >>> - libsec e.g. calls pathconf(name, _PC_ACL_ENABLED) in order to = find >>> the ACL type that is used for a file and controls which ACL = flavor to=20 >>> retrieve. >>=20 >> Use the usual pathconf(3), with _PC_ACL_NFS4. >=20 > This looks like an interface that is not optimized for performance. If you call it only once per filesystem, the performance is not an = issue. Libarchive caches filesystem properties as it traverses the tree, so it would have no problem with this. But there are also filesystems (AIX, I think) that permit different types of ACLs on different files in the same file system. I would like to see a bit added to stat() indicating the presence of either POSIX.1e or NFSv4 ACLs so that clients can efficiently determine this on a per-file basis. Tim From owner-posix1e@FreeBSD.ORG Thu Nov 7 14:36:05 2013 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5AC8EB9D for ; Thu, 7 Nov 2013 14:36:05 +0000 (UTC) (envelope-from joerg.schilling@fokus.fraunhofer.de) Received: from mx-relay04-dus.antispameurope.com (mx-relay04-dus.antispameurope.com [94.100.134.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B2529249D for ; Thu, 7 Nov 2013 14:36:04 +0000 (UTC) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by mx-gate04-dus.antispameurope.com; Thu, 07 Nov 2013 15:34:43 +0100 Received: from DIRAC.fokus.fraunhofer.de (dirac.fokus.fraunhofer.de [10.147.9.201]) by pluto.fokus.fraunhofer.de (8.14.4/8.14.2) with ESMTP id rA7EYKEd012238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Nov 2013 15:34:20 +0100 (CET) Received: from rigel (10.147.13.100) by DIRAC.fokus.fraunhofer.de (10.147.9.201) with Microsoft SMTP Server id 14.3.158.1; Thu, 7 Nov 2013 15:34:20 +0100 Date: Thu, 7 Nov 2013 15:34:20 +0100 From: Joerg Schilling To: Subject: Re: NFSv4 ACL support in star Message-ID: <527ba4ec.e9TOPksWy6wOFrCx%Joerg.Schilling@fokus.fraunhofer.de> References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> <5AB09353-50C8-4909-8CEB-27E2DA722C7E@FreeBSD.org> <527b752f.5Y++ut7T0v9V9Hs6%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-KSE-Antivirus-Interceptor-Info: protection disabled X-cloud-security-sender: joerg.schilling@fokus.fraunhofer.de X-cloud-security-recipient: posix1e@freebsd.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate04-dus with 51DA7388001C X-cloud-security-connect: pluto.fokus.fraunhofer.de[195.37.77.164], TLS=, IP=195.37.77.164 X-cloud-security: scantime:.9056 X-Mailman-Approved-At: Thu, 07 Nov 2013 18:31:21 +0000 Cc: star-developers@lists.berlios.de, posix1e@FreeBSD.org, ryao@gentoo.org, ag@bestbits.at, praiskup@redhat.com, pjd@FreeBSD.org, behlendorf1@llnl.gov X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:36:05 -0000 Tim Kientzle wrote: > >> Use the usual pathconf(3), with _PC_ACL_NFS4. > > > > This looks like an interface that is not optimized for performance. > > If you call it only once per filesystem, the performance is not an issue. > Libarchive caches filesystem properties as it traverses the tree, > so it would have no problem with this. Then you need to call stat() for every file or need to know every mount point, that might be a single file... > But there are also filesystems (AIX, I think) that permit different > types of ACLs on different files in the same file system. > > I would like to see a bit added to stat() indicating the presence of > either POSIX.1e or NFSv4 ACLs so that clients can efficiently > determine this on a per-file basis. SCO UnixWare uses the UFS ACL implementation from SVr4/Solaris but added a st_aclcnt field in struct stat. Do you have free space in strct stat on BSD? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-posix1e@FreeBSD.ORG Fri Nov 8 07:26:34 2013 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DF5EA4A6 for ; Fri, 8 Nov 2013 07:26:34 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id A249D24F8 for ; Fri, 8 Nov 2013 07:26:34 +0000 (UTC) Received: from localhost (unknown [75.144.245.226]) by mail.dawidek.net (Postfix) with ESMTPSA id 626CE1C6; Fri, 8 Nov 2013 08:20:12 +0100 (CET) Date: Fri, 8 Nov 2013 08:26:29 +0100 From: Pawel Jakub Dawidek To: Joerg Schilling Subject: Re: NFSv4 ACL support in star Message-ID: <20131108072628.GA1140@garage.freebsd.pl> References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> <5AB09353-50C8-4909-8CEB-27E2DA722C7E@FreeBSD.org> <527b752f.5Y++ut7T0v9V9Hs6%Joerg.Schilling@fokus.fraunhofer.de> <527ba4ec.e9TOPksWy6wOFrCx%Joerg.Schilling@fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <527ba4ec.e9TOPksWy6wOFrCx%Joerg.Schilling@fokus.fraunhofer.de> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 08 Nov 2013 12:43:18 +0000 Cc: star-developers@lists.berlios.de, praiskup@redhat.com, ryao@gentoo.org, ag@bestbits.at, posix1e@FreeBSD.org, behlendorf1@llnl.gov, kientzle@acm.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 07:26:34 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 07, 2013 at 03:34:20PM +0100, Joerg Schilling wrote: > Tim Kientzle wrote: >=20 > > >> Use the usual pathconf(3), with _PC_ACL_NFS4. > > >=20 > > > This looks like an interface that is not optimized for performance. > > > > If you call it only once per filesystem, the performance is not an issu= e. > > Libarchive caches filesystem properties as it traverses the tree, > > so it would have no problem with this. >=20 > Then you need to call stat() for every file or need to know every mount p= oint,=20 > that might be a single file... >=20 > > But there are also filesystems (AIX, I think) that permit different > > types of ACLs on different files in the same file system. > > > > I would like to see a bit added to stat() indicating the presence of > > either POSIX.1e or NFSv4 ACLs so that clients can efficiently > > determine this on a per-file basis. >=20 > SCO UnixWare uses the UFS ACL implementation from SVr4/Solaris but added a > st_aclcnt field in struct stat. Do you have free space in strct stat on B= SD? We do have a spare field, but for FreeBSD 11 we have to move to 64bit inodes, so we won't avoid changing the stat structure. If we need it sooner then I believe the spare field is up for grabs. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlJ8kiQACgkQForvXbEpPzT37gCgzdtDhKkUMQlwz3gVtRjPg/qR JgkAn1XoLKZJBx5LzI1iE6Nsj+Emxw18 =VcFO -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From owner-posix1e@FreeBSD.ORG Fri Nov 8 18:10:24 2013 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C3589141; Fri, 8 Nov 2013 18:10:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 98E1728B2; Fri, 8 Nov 2013 18:10:24 +0000 (UTC) Received: from c0153.aw.cl.cam.ac.uk (c0153.aw.cl.cam.ac.uk [128.232.100.153]) by cyrus.watson.org (Postfix) with ESMTPSA id 7583346B0D; Fri, 8 Nov 2013 13:10:15 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: NFSv4 ACL support in star From: "Robert N. M. Watson" In-Reply-To: <20131108072628.GA1140@garage.freebsd.pl> Date: Fri, 8 Nov 2013 18:10:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <378F5E86-D108-4891-A750-5857E54C75D9@FreeBSD.org> References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> <5AB09353-50C8-4909-8CEB-27E2DA722C7E@FreeBSD.org> <527b752f.5Y++ut7T0v9V9Hs6%Joerg.Schilling@fokus.fraunhofer.de> <527ba4ec.e9TOPksWy6wOFrCx%Joerg.Schilling@fokus.fraunhofer.de> <20131108072628.GA1140@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1822) Cc: star-developers@lists.berlios.de, Joerg Schilling , praiskup@redhat.com, ryao@gentoo.org, ag@bestbits.at, posix1e@FreeBSD.org, behlendorf1@llnl.gov, kientzle@acm.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 18:10:24 -0000 On 8 Nov 2013, at 07:26, Pawel Jakub Dawidek wrote: >>> But there are also filesystems (AIX, I think) that permit different >>> types of ACLs on different files in the same file system. >>>=20 >>> I would like to see a bit added to stat() indicating the presence of >>> either POSIX.1e or NFSv4 ACLs so that clients can efficiently >>> determine this on a per-file basis. >>=20 >> SCO UnixWare uses the UFS ACL implementation from SVr4/Solaris but = added a >> st_aclcnt field in struct stat. Do you have free space in strct stat = on BSD? >=20 > We do have a spare field, but for FreeBSD 11 we have to move to 64bit > inodes, so we won't avoid changing the stat structure. If we need it > sooner then I believe the spare field is up for grabs. We actually meant to sort out a bit for this when we first did POSIX.1e = ACLs in FreeBSD ... 5? But somehow it never happened. There are actually = some interesting features here beyond hinting to userspace that it wants = to check for extended protection -- we might also want to use it to hint = to the ACL implementation that it might not need to search for ACL = meta-data in the extended attribute implementation as well. This, of = course, further cements the need for proper atomicity properties with = respect to soft updates/etc if it becomes an optimisation (i.e., you = want to be sure that if an ACL is present, the bit is always set, even = if a crash took place as the ACL was added, but don't mind so much if = it's the other way around). A general "status bits" field in the new = stat structure would make sense anyway -- I can imagine wanting to hint = other aspects (e.g., the presence of user attributes) there as well. Robert= From owner-posix1e@FreeBSD.ORG Sat Nov 9 21:15:49 2013 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3047A544 for ; Sat, 9 Nov 2013 21:15:49 +0000 (UTC) (envelope-from joerg.schilling@fokus.fraunhofer.de) Received: from mx-relay05-dus.antispameurope.com (mx-relay05-dus.antispameurope.com [94.100.134.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8BBBF23A5 for ; Sat, 9 Nov 2013 21:15:47 +0000 (UTC) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by mx-gate05-dus.antispameurope.com; Sat, 09 Nov 2013 22:15:38 +0100 Received: from DIRAC.fokus.fraunhofer.de (dirac.fokus.fraunhofer.de [10.147.9.201]) by pluto.fokus.fraunhofer.de (8.14.4/8.14.2) with ESMTP id rA9LFYui006237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sat, 9 Nov 2013 22:15:34 +0100 (CET) Received: from rigel (10.147.13.100) by DIRAC.fokus.fraunhofer.de (10.147.9.201) with Microsoft SMTP Server id 14.3.158.1; Sat, 9 Nov 2013 22:15:34 +0100 Date: Sat, 9 Nov 2013 22:15:34 +0100 From: Joerg Schilling To: Subject: Re: NFSv4 ACL support in star Message-ID: <527ea5f6.AxRYlGZONWc37hhi%Joerg.Schilling@fokus.fraunhofer.de> References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> <5AB09353-50C8-4909-8CEB-27E2DA722C7E@FreeBSD.org> <527b752f.5Y++ut7T0v9V9Hs6%Joerg.Schilling@fokus.fraunhofer.de> <527ba4ec.e9TOPksWy6wOFrCx%Joerg.Schilling@fokus.fraunhofer.de> <20131108072628.GA1140@garage.freebsd.pl> In-Reply-To: <20131108072628.GA1140@garage.freebsd.pl> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-KSE-Antivirus-Interceptor-Info: protection disabled X-cloud-security-sender: joerg.schilling@fokus.fraunhofer.de X-cloud-security-recipient: posix1e@freebsd.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate05-dus with 8325B10A0003 X-cloud-security-connect: pluto.fokus.fraunhofer.de[195.37.77.164], TLS=, IP=195.37.77.164 X-cloud-security: scantime:.2139 X-Mailman-Approved-At: Sat, 09 Nov 2013 21:34:10 +0000 Cc: star-developers@lists.berlios.de, praiskup@redhat.com, ryao@gentoo.org, ag@bestbits.at, posix1e@FreeBSD.org, behlendorf1@llnl.gov, kientzle@acm.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 21:15:49 -0000 Pawel Jakub Dawidek wrote: > > SCO UnixWare uses the UFS ACL implementation from SVr4/Solaris but added a > > st_aclcnt field in struct stat. Do you have free space in strct stat on BSD? > > We do have a spare field, but for FreeBSD 11 we have to move to 64bit > inodes, so we won't avoid changing the stat structure. If we need it > sooner then I believe the spare field is up for grabs. If you do this kind of a change, do you also change towards a 64 bit time_t for the file times? OK, back to the ACL/tar topic. Star is ready now fopr Solaris: ftp://ftp.berlios.de/pub/schily/schily-2013-11-09.tar.bz2 I tried to convert the acl test archives from Andreas Grünbacher from 2001. I did this by unpacking the archives using star on ZFS and then repacked the files from ZFS. They are not at: ftp://ftp.berlios.de/pub/star/alpha/acl-nfsv4-* It seems that the POSIX-draft -> NFSv4 ACL converter from Solaris libsec is not optimal as it adds superfluous ACE entries. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-posix1e@FreeBSD.ORG Sun Nov 10 12:19:00 2013 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CD305F36; Sun, 10 Nov 2013 12:19:00 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 101582726; Sun, 10 Nov 2013 12:18:59 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id c4so376216eek.18 for ; Sun, 10 Nov 2013 04:18:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=L/HIsS5aJzTHHSDzD6Wi+QW5t0hWU7eFDwVZRZF1A1Q=; b=0DwdghXR35lZog/FnjQGAEtOHyZp5XYvYDl6WC5Q70IwvH1PC1SbD10YWoPCTz/QJ6 00jcSBJeeBI0sSps06xMUvCfVJwcKesMILJOeoTb3/nCDqRck/NqZc/R295Yaxaap1TC apTofaHsNqZGu3NVd8wNsF6KQqjt5xvWBDD973/Hy8YGVZk+HMQKZNcPUZVLo3AiLuzA /FjihWqmDKWLM8TDSLf+YbuddbrWhA0E9iujJGDFmJlEN7w7zqy7VX1HJSbgkpuP6tfi A+bfnKU1s/ZACQmwWK8w24R6OhSCa+dACpRlMubJ8yWhDBf/InJ7ndv1mdY/DljOaPJd 4J0w== X-Received: by 10.14.3.130 with SMTP id 2mr11604429eeh.36.1384085938461; Sun, 10 Nov 2013 04:18:58 -0800 (PST) Received: from [192.168.1.102] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPSA id z2sm48615598eee.7.2013.11.10.04.18.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Nov 2013 04:18:57 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: NFSv4 ACL support in star Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <527b752f.5Y++ut7T0v9V9Hs6%Joerg.Schilling@fokus.fraunhofer.de> Date: Sun, 10 Nov 2013 13:18:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9436F980-8384-429B-A997-126276B151F7@FreeBSD.org> References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> <5AB09353-50C8-4909-8CEB-27E2DA722C7E@FreeBSD.org> <527b752f.5Y++ut7T0v9V9Hs6%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg Schilling X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Sun, 10 Nov 2013 12:40:54 +0000 Cc: star-developers@lists.berlios.de, posix1e@FreeBSD.org, ryao@gentoo.org, ag@bestbits.at, praiskup@redhat.com, pjd@FreeBSD.org, behlendorf1@llnl.gov, kientzle@acm.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 12:19:00 -0000 Wiadomo=B6=E6 napisana przez Joerg Schilling w dniu 7 lis 2013, o godz. = 12:10: > Edward Tomasz Napiera?a wrote: >=20 >>> I like to see an implementation that (if implemented as an = enhancement of the >>> withdrawn POSIX.1e ACL interfaces) gives similar features as libsec = does: >>=20 >> In order to make FreeBSD support NFSv4, I did exactly that: I've = added >> a number of functions, such as acl_get_entry_type_np(3) (basically, = this >> is for "allow/deny" part of ACL), and extended existing ones, e.g. to = add >> new permissions. >=20 > This looks like a missunderstanding: >=20 > I am not interested in single entries but in the currnt state of the = acl_t=20 > object. >=20 > acl_type(aclp) returns: >=20 > ACLENT_T =3D 0, UFS ACLs (compatible with POSIX draft) > ACE_T =3D 1 NFSv4 ACLs >=20 > I need to know whether to create >=20 > SCHILX.acl.access > and > SCHILY.acl.default >=20 > keywords or=20 >=20 > SCHILY.acl.ace >=20 > before I convert things and I don't like to parse the text... Okay, so this is what acl_get_brand_np() is for. The = acl_get_entry_type_np() returns NFSv4 entry type, i.e. whether it's "allow", or "deny". >>> - libsec e.g. calls pathconf(name, _PC_ACL_ENABLED) in order to = find >>> the ACL type that is used for a file and controls which ACL = flavor to=20 >>> retrieve. >>=20 >> Use the usual pathconf(3), with _PC_ACL_NFS4. >=20 > This looks like an interface that is not optimized for performance. >=20 > pathconf(name, _PC_ACL_ENABLED) >=20 > returns >=20 > _ACL_ACLENT_ENABLED (1) if the filesystem supports UFS ACLs > _ACL_ACE_ENABLED (2) if the filesystem supportfs NFSv4 ACLs >=20 > or a bitwise or of both. >=20 > But if you implement another performant method I am OK.=20 As Tim said, you probably already need to call stat on every file added; just reuse the value returned by pathconf if st_dev for the file is the same as st_dev for the previous file. That's what all the utilities such as ls(1) do >>> - libsec includes code to deal with ephemeral IDs used with CIFS = clients. >>=20 >> Hm, isn't this independent from ACL implementation? >=20 > It may look so but there are related ACE entries and these ACEs carry = ephemeral=20 > UID/GID values. Ah, the appended ID. So, acl_to_text_np(3) takes ACL_TEXT_APPEND_ID = flag, which makes it output textual form with appended IDs; the = acl_from_text(3) handles appended ID automatically. >>> - libsec offers acl_type(aclp) to find the ACl type without a need = to >>> call acl_totext(), so I could use: >>=20 >> See acl_get_brand_np(). >=20 > OK, this is what I am interested in. Ok. >>> I am in hope that we could get a final library interface that still = stays=20 >>> compatible between FreeBSD and Linux as this was the base for being = able to=20 >>> support more platforms with POSIX.1e draft ACLs. >>=20 >> I think porting what I did would be a good choice - it's fully = backwards >> compatible, API-wise, and not actually hacky. >=20 > Well, it would be nice to see feedback from Linux people. Definitely. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-posix1e@FreeBSD.ORG Sun Nov 10 12:28:21 2013 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 83F89FB3; Sun, 10 Nov 2013 12:28:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 5A0FE2775; Sun, 10 Nov 2013 12:28:21 +0000 (UTC) Received: from [10.0.1.16] (host86-132-107-1.range86-132.btcentralplus.com [86.132.107.1]) by cyrus.watson.org (Postfix) with ESMTPSA id BC5E646B2A; Sun, 10 Nov 2013 07:28:17 -0500 (EST) Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: NFSv4 ACL support in star From: "Robert N. M. Watson" In-Reply-To: <9436F980-8384-429B-A997-126276B151F7@FreeBSD.org> Date: Sun, 10 Nov 2013 12:28:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> <5AB09353-50C8-4909-8CEB-27E2DA722C7E@FreeBSD.org> <527b752f.5Y++ut7T0v9V9Hs6%Joerg.Schilling@fokus.fraunhofer.de> <9436F980-8384-429B-A997-126276B151F7@FreeBSD.org> To: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= X-Mailer: Apple Mail (2.1822) X-Mailman-Approved-At: Sun, 10 Nov 2013 12:41:03 +0000 Cc: star-developers@lists.berlios.de, Joerg Schilling , praiskup@redhat.com, ryao@gentoo.org, ag@bestbits.at, posix1e@FreeBSD.org, Pawel Jakub Dawidek , behlendorf1@llnl.gov, kientzle@acm.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 12:28:21 -0000 On 10 Nov 2013, at 12:18, Edward Tomasz Napiera=B3a = wrote: >>>> I am in hope that we could get a final library interface that still = stays=20 >>>> compatible between FreeBSD and Linux as this was the base for being = able to=20 >>>> support more platforms with POSIX.1e draft ACLs. >>>=20 >>> I think porting what I did would be a good choice - it's fully = backwards >>> compatible, API-wise, and not actually hacky. >>=20 >> Well, it would be nice to see feedback from Linux people. >=20 > Definitely. FWIW, and perhaps this is obvious to all, but: FreeBSD, Linux, and Mac = OS X share portions of their ACL library APIs, documentation, and = implementation (although the degree varies a lot). It would be nice if = sensible improvements made to one could be propagated to the others, as = this would make life for application writers substantially easier. Some = differences are now long-since committed to -- e.g., although Mac OS X = picked up the FreeBSD ACL library and API, that was before FreeBSD = supported NFSv4 ACLs, and Apple was uninterested in POSIX.1e, so there = are necessary differences in the FreeBSD implementation of NFSv4 ACLs. = But we should do the best we can to be consistent. One way to do this is = to have a common test suite that is aware of intentional differences but = tries otherwise to consistently check behaviour that applications like = tar, rsync, etc, depend on. Robert= From owner-posix1e@FreeBSD.ORG Sun Nov 10 17:12:06 2013 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0A33571A for ; Sun, 10 Nov 2013 17:12:06 +0000 (UTC) (envelope-from joerg.schilling@fokus.fraunhofer.de) Received: from mx-relay14-dus.antispameurope.com (mx-relay14-dus.antispameurope.com [94.100.134.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 63A4225BD for ; Sun, 10 Nov 2013 17:12:04 +0000 (UTC) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by mx-gate14-dus.antispameurope.com; Sun, 10 Nov 2013 18:11:21 +0100 Received: from FEYNMAN.fokus.fraunhofer.de (feynman.fokus.fraunhofer.de [10.147.9.202]) by pluto.fokus.fraunhofer.de (8.14.4/8.14.2) with ESMTP id rAAHBHIV016334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 10 Nov 2013 18:11:18 +0100 (CET) Received: from rigel (10.147.13.100) by FEYNMAN.fokus.fraunhofer.de (10.147.9.202) with Microsoft SMTP Server id 14.3.158.1; Sun, 10 Nov 2013 18:11:16 +0100 Date: Sun, 10 Nov 2013 18:11:17 +0100 From: Joerg Schilling To: Subject: Re: NFSv4 ACL support in star Message-ID: <527fbe35.TxSQ9RfMwtjkT3s7%Joerg.Schilling@fokus.fraunhofer.de> References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> <5AB09353-50C8-4909-8CEB-27E2DA722C7E@FreeBSD.org> <527b752f.5Y++ut7T0v9V9Hs6%Joerg.Schilling@fokus.fraunhofer.de> <9436F980-8384-429B-A997-126276B151F7@FreeBSD.org> In-Reply-To: <9436F980-8384-429B-A997-126276B151F7@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-KSE-Antivirus-Interceptor-Info: protection disabled X-cloud-security-sender: joerg.schilling@fokus.fraunhofer.de X-cloud-security-recipient: posix1e@freebsd.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate14-dus with 6FA9E2118001 X-cloud-security-connect: pluto.fokus.fraunhofer.de[195.37.77.164], TLS=, IP=195.37.77.164 X-cloud-security: scantime:.1808 X-Mailman-Approved-At: Sun, 10 Nov 2013 22:35:12 +0000 Cc: star-developers@lists.berlios.de, posix1e@FreeBSD.org, ryao@gentoo.org, ag@bestbits.at, praiskup@redhat.com, pjd@FreeBSD.org, behlendorf1@llnl.gov, kientzle@acm.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 17:12:06 -0000 Edward Tomasz Napiera?a wrote: > >> Use the usual pathconf(3), with _PC_ACL_NFS4. > > > > This looks like an interface that is not optimized for performance. > > > > pathconf(name, _PC_ACL_ENABLED) > > > > returns > > > > _ACL_ACLENT_ENABLED (1) if the filesystem supports UFS ACLs > > _ACL_ACE_ENABLED (2) if the filesystem supportfs NFSv4 ACLs > > > > or a bitwise or of both. > > > > But if you implement another performant method I am OK. > > As Tim said, you probably already need to call stat on every file > added; just reuse the value returned by pathconf if st_dev for the > file is the same as st_dev for the previous file. That's what all > the utilities such as ls(1) do The problem I see is that star first calls lstat() and the acl library would to it again... On my development system, star needs 8 usec per empty file to archive (in case it is told to create the enhanced pax format I call "exustar"). It takes 40 additional usecs if I let it archive ACLs also. It would be nice if there is less additional time and this tells me that I need to check libsec for possible improvements. > > It may look so but there are related ACE entries and these ACEs carry ephemeral > > UID/GID values. > > Ah, the appended ID. So, acl_to_text_np(3) takes ACL_TEXT_APPEND_ID flag, > which makes it output textual form with appended IDs; the acl_from_text(3) > handles appended ID automatically. Star needs to do this in order to implement the option -numeric and this is why I prepare the ACL text data before I give it to acl_fromtext(). > > Well, it would be nice to see feedback from Linux people. > > Definitely. Let's see whether there is feedback. It may be that there is currently still room for a change on both sides. Once people start to implement portable applications that support FreeBSD also, Linux may be forced to implement something compatible to FreeBSD. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-posix1e@FreeBSD.ORG Sun Nov 10 17:15:28 2013 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AB16F755 for ; Sun, 10 Nov 2013 17:15:28 +0000 (UTC) (envelope-from joerg.schilling@fokus.fraunhofer.de) Received: from mx-relay13-dus.antispameurope.com (mx-relay13-dus.antispameurope.com [94.100.134.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 11B3A25E0 for ; Sun, 10 Nov 2013 17:15:27 +0000 (UTC) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by mx-gate13-dus.antispameurope.com; Sun, 10 Nov 2013 18:15:19 +0100 Received: from FEYNMAN.fokus.fraunhofer.de (feynman.fokus.fraunhofer.de [10.147.9.202]) by pluto.fokus.fraunhofer.de (8.14.4/8.14.2) with ESMTP id rAAHFIsn016371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 10 Nov 2013 18:15:19 +0100 (CET) Received: from rigel (10.147.13.100) by FEYNMAN.fokus.fraunhofer.de (10.147.9.202) with Microsoft SMTP Server id 14.3.158.1; Sun, 10 Nov 2013 18:15:17 +0100 Date: Sun, 10 Nov 2013 18:15:18 +0100 From: Joerg Schilling To: , Subject: Re: NFSv4 ACL support in star Message-ID: <527fbf26.P9LWZX6YvFSedyGc%Joerg.Schilling@fokus.fraunhofer.de> References: <5278fa92.hHrZwSJqi2nC7MFT%Joerg.Schilling@fokus.fraunhofer.de> <5278FE88.1070204@gentoo.org> <527905dc.KOdFZjwBLc1hsTuO%Joerg.Schilling@fokus.fraunhofer.de> <527a7edd.FGUebtA4aMDuWedS%Joerg.Schilling@fokus.fraunhofer.de> <5AB09353-50C8-4909-8CEB-27E2DA722C7E@FreeBSD.org> <527b752f.5Y++ut7T0v9V9Hs6%Joerg.Schilling@fokus.fraunhofer.de> <9436F980-8384-429B-A997-126276B151F7@FreeBSD.org> In-Reply-To: User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-KSE-Antivirus-Interceptor-Info: protection disabled X-cloud-security-sender: joerg.schilling@fokus.fraunhofer.de X-cloud-security-recipient: posix1e@freebsd.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate13-dus with 8558E2118003 X-cloud-security-connect: pluto.fokus.fraunhofer.de[195.37.77.164], TLS=, IP=195.37.77.164 X-cloud-security: scantime:.1378 X-Mailman-Approved-At: Sun, 10 Nov 2013 22:37:21 +0000 Cc: star-developers@lists.berlios.de, praiskup@redhat.com, ryao@gentoo.org, ag@bestbits.at, posix1e@freebsd.org, pjd@freebsd.org, behlendorf1@llnl.gov, kientzle@acm.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 17:15:28 -0000 "Robert N. M. Watson" wrote: > FWIW, and perhaps this is obvious to all, but: FreeBSD, Linux, and Mac OS X share portions of their ACL library APIs, documentation, and implementation (although the degree varies a lot). It would be nice if sensible improvements made to one could be propagated to the others, as this would make life for application writers substantially easier. Some differences are now long-since committed to -- e.g., although Mac OS X picked up the FreeBSD ACL library and API, that was before FreeBSD supported NFSv4 ACLs, and Apple was uninterested in POSIX.1e, so there are necessary differences in the FreeBSD implementation of NFSv4 ACLs. But we should do the best we can to be consistent. One way to do this is to have a common test suite that is aware of intentional differences but tries otherwise to consistently check behaviour that applications like tar, rsync, etc, depend on. The current code in star to support POSIX.1e draft ACLs is nearly identical for FreeBSD and Linux. There is currently only a difference when clearing ACLs for a file. If the code to support NFSv4 ACLs has more differences, it may be impossible to support both platforms in a single maintainable program. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-posix1e@FreeBSD.ORG Sun Jul 13 15:15:39 2014 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F6F7F97 for ; Sun, 13 Jul 2014 15:15:39 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6CCF2E58 for ; Sun, 13 Jul 2014 15:15:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1405264533; l=5289; s=domk; d=obsigna.com; h=Mime-Version:To:Date:Subject:Content-Type:From; bh=zHNqVVQ0CROC9LsiyDFvM35wrNw=; b=WlA47ITUNB1SMgFxP9x99JGmLNTHwY+Cur5aoIwbLe8I3DPh3vBWKq/s32kyx7mMp5Z T79x/UtMcDzcq5US+fy9YUKDDhr5FrovoWlo5QwcsiofV4htnazz2rVnU9ER/ZOViN46h ftMNsh90pcPDZb6uetII+DPRUwyUiVgeeVg= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU1DqWLqtDlVqo50LuK X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (c94a6333.virtua.com.br [201.74.99.51]) by smtp.strato.de (RZmta 35.2 DYNA|AUTH) with ESMTPSA id j02c80q6DFFXRlN (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) for ; Sun, 13 Jul 2014 17:15:33 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id ADA33FA47919 for ; Sun, 13 Jul 2014 12:15:30 -0300 (BRT) From: "Dr. Rolf Jansen" Subject: Non-trivial ACLs only? Message-Id: <6DF892D7-F4E2-4010-8AB9-5C798ED9C36B@obsigna.com> Date: Sun, 13 Jul 2014 12:15:29 -0300 To: posix1e@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 15:15:39 -0000 Is there an easy (one-pass) way to retrieve only non-trivial ACLs from a = file system item? In the course of the speed optimization of my file system cloning tool = https://code.google.com/p/clone/ for FreeBSD and Mac OS X, I found out = that on FreeBSD-UFS2 (ACL enabled) the function acl_get_link_np() = returns also the standard access rights as ACL, and my tool did an = unnecessarily extraordinary work in fetching this from the original and = storing it to the cloned file system items. For millions of files, the = extra spent time sums up to hours. On Mac OS X, acl_get_link_np() returns real ACLs only, can I have this = somehow for FreeBSD too? For the time being I came up with the following quite involved solution: // reading the ACLs int trivial; if ((xmd->acl[0] =3D acl_get_link_np(src, ACL_TYPE_ACCESS)) && (acl_is_trivial_np(xmd->acl[0], &trivial) || trivial)) { acl_free(xmd->acl[0]); xmd->acl[0] =3D NULL; } if ((xmd->acl[1] =3D acl_get_link_np(src, ACL_TYPE_DEFAULT)) && (acl_is_trivial_np(xmd->acl[1], &trivial) || trivial)) { acl_free(xmd->acl[1]); xmd->acl[1] =3D NULL; } if ((xmd->acl[2] =3D acl_get_link_np(src, ACL_TYPE_NFS4)) && (acl_is_trivial_np(xmd->acl[2], &trivial) || trivial)) { acl_free(xmd->acl[2]); xmd->acl[2] =3D NULL; } This doesn't seem to work properly for directories, any ideas why? Isn't there a better way? Is it really necessary to assemble the standard access rights into an = ACL, I did not expect this, Mac OS X doesn't do this, and in the present = situation it spoils up everything. Anyway, for the present purpose it would be great to have at least a = function which simply informs whether a file system item got a = non-trivial ACL or not, without actually needing to load that ACL into = memory. Many thanks Rolf Jansen From owner-posix1e@FreeBSD.ORG Sun Jul 13 18:55:17 2014 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39E142D7 for ; Sun, 13 Jul 2014 18:55:17 +0000 (UTC) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4C112FA5 for ; Sun, 13 Jul 2014 18:55:13 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id q59so3197181wes.12 for ; Sun, 13 Jul 2014 11:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=44K4+0ZUcGlIEoqURveNzm0bYJ2klBjqvSDdFmnrsrg=; b=kKVSyaxrelm4pY+hsdJ9WLhNJdhFWMciPOFwZDAIFmZp5fRjczsKtFqZJmzuhdI09K mRVVMc1VRSFzDqK/8OLNQ7tvOwwCTMTHSbBhixNX4Uf79oqp2TqsJKfKLGSMDPC8YVZK PX8Iq+WofsiUMOEbV+Pi14dc5egNQikBVhSC7PEvyJ4O16Espc+O64O5eBhZ40EbFYmR u0bUoB40Ix+xQUmXTN+QXHE6qdkkPffFeqiKhyoEFV6CSvwW7v/TbkNVLMYe+ZoUaltq rGnty5ZbIqQAP9DsiEts25kTzLbpW1+Z4FrPSwfIPfm39P8T+jL1t9PLXoXy/jf9O+sW IjVg== X-Received: by 10.180.92.73 with SMTP id ck9mr15316731wib.54.1405277712039; Sun, 13 Jul 2014 11:55:12 -0700 (PDT) Received: from brick.home (abpj92.neoplus.adsl.tpnet.pl. [83.8.51.92]) by mx.google.com with ESMTPSA id ey16sm21772199wid.14.2014.07.13.11.55.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Jul 2014 11:55:11 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sun, 13 Jul 2014 20:55:09 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "Dr. Rolf Jansen" Subject: Re: Non-trivial ACLs only? Message-ID: <20140713185509.GA8996@brick.home> References: <6DF892D7-F4E2-4010-8AB9-5C798ED9C36B@obsigna.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6DF892D7-F4E2-4010-8AB9-5C798ED9C36B@obsigna.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: posix1e@FreeBSD.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 18:55:17 -0000 On 0713T1215, Dr. Rolf Jansen wrote: > Is there an easy (one-pass) way to retrieve only non-trivial ACLs from a file system item? > > In the course of the speed optimization of my file system cloning tool https://code.google.com/p/clone/ for FreeBSD and Mac OS X, I found out that on FreeBSD-UFS2 (ACL enabled) the function acl_get_link_np() returns also the standard access rights as ACL, and my tool did an unnecessarily extraordinary work in fetching this from the original and storing it to the cloned file system items. For millions of files, the extra spent time sums up to hours. > > On Mac OS X, acl_get_link_np() returns real ACLs only, can I have this somehow for FreeBSD too? No, because it's a bug. Unfortunately I don't expect Apple to fix their implementation. > For the time being I came up with the following quite involved solution: > > // reading the ACLs > int trivial; > > if ((xmd->acl[0] = acl_get_link_np(src, ACL_TYPE_ACCESS)) && > (acl_is_trivial_np(xmd->acl[0], &trivial) || trivial)) > { > acl_free(xmd->acl[0]); > xmd->acl[0] = NULL; > } > > if ((xmd->acl[1] = acl_get_link_np(src, ACL_TYPE_DEFAULT)) && > (acl_is_trivial_np(xmd->acl[1], &trivial) || trivial)) > { > acl_free(xmd->acl[1]); > xmd->acl[1] = NULL; > } This one is wrong. There is no such thing as trivial default ACL. If you can actually retrieve ACL_TYPE_DEFAULT ACL and there are any entries in it, it's non-trivial. > if ((xmd->acl[2] = acl_get_link_np(src, ACL_TYPE_NFS4)) && > (acl_is_trivial_np(xmd->acl[2], &trivial) || trivial)) > { > acl_free(xmd->acl[2]); > xmd->acl[2] = NULL; > } > > This doesn't seem to work properly for directories, any ideas why? I think it's the problem above. > Isn't there a better way? Actually, there is. You try to obtain both POSIX and NFSv4 ACLs for every file, even though the filesystem can always support either one, or the other. Take a look how eg. the cp(1) utility does it. The source code is here: http://svnweb.freebsd.org/base/head/bin/cp/utils.c?revision=245960&view=markup Look for preserve_fd_acls() function. > Is it really necessary to assemble the standard access rights into an ACL, I did not expect this, Mac OS X doesn't do this, and in the present situation it spoils up everything. Well, yes, because the standard UNIX permissions are a part of ACL by definition. > Anyway, for the present purpose it would be great to have at least a function which simply informs whether a file system item got a non-trivial ACL or not, without actually needing to load that ACL into memory. I don't think there would be any measurable speedup. You still need to use a syscall to do this, and the syscall would need to access ACL metadata. The only difference from what you're doing right now is calling acl_is_trivial_np() and perhaps acl_free(), which are both just a library functions, and thus cheap. From owner-posix1e@FreeBSD.ORG Mon Jul 14 01:02:26 2014 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2ABBED0D; Mon, 14 Jul 2014 01:02:26 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 845A32A07; Mon, 14 Jul 2014 01:02:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1405299741; l=3939; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=2nqmRKz4l+ADE/Z8pen2Ajf5hTQ=; b=cpudw6CqBY3y/DyCVFWUSsAP/qE/O3pI1ZMKqg7WqM/e8srMyooqby2tIf1r+bn/yIc ejWBwP+4Tm7XxZEisR359P9qain51WWEBOkIQe8F0DrS+N5WbLpC61rheXzVe10y9cdFz jXmXO/gfDjSTvSGvcasBt6kPgE9gRDPnhZM= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU1DqWLqtDlVqo50LuK X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (c94a6333.virtua.com.br [201.74.99.51]) by smtp.strato.de (RZmta 35.2 DYNA|AUTH) with ESMTPSA id v03875q6E12KT4e (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Mon, 14 Jul 2014 03:02:20 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 89726FA47919; Sun, 13 Jul 2014 22:02:12 -0300 (BRT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Non-trivial ACLs only? From: "Dr. Rolf Jansen" In-Reply-To: <20140713185509.GA8996@brick.home> Date: Sun, 13 Jul 2014 22:02:10 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <85785513-4D5F-4DCA-B1E4-2134C5AEAD22@obsigna.com> References: <6DF892D7-F4E2-4010-8AB9-5C798ED9C36B@obsigna.com> <20140713185509.GA8996@brick.home> To: posix1e@FreeBSD.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 01:02:26 -0000 Am 13.07.2014 um 15:55 schrieb Edward Tomasz Napiera=C5=82a = : > On 0713T1215, Dr. Rolf Jansen wrote: >>=20 >> ... >> On Mac OS X, acl_get_link_np() returns real ACLs only, can I have = this somehow for FreeBSD too? >=20 > No, because it's a bug. Unfortunately I don't expect Apple to fix = their implementation. If it's a bug, then for my purpose it's a very welcome one, because it = keeps things easy on Mac OS X. So, I hope Apple keeps it as it is.=20 > This one is wrong. There is no such thing as trivial default > ACL. If you can actually retrieve ACL_TYPE_DEFAULT ACL and > there are any entries in it, it's non-trivial. >=20 > ... >=20 >> This doesn't seem to work properly for directories, any ideas why? >=20 > I think it's the problem above. OK, how then can I find out if there are ACLs set on directories or not. = Please consider the following code snippet: #include #include #include #include int main(int argc, char *const argv[]) { mkdir("test_acl_dir", 0755); if (acl_get_link_np("test_acl_dir", ACL_TYPE_DEFAULT)) printf("ACL found.\n"); else printf("ACL not found.\n"); return 0; } clang acltest.c -o acltest rm -rf test_acl_dir && ./acltest On FreeBSD 9.2, the above command sequence results in "ACL found." = Actually no ACL has been set, and I would have expected, that any = acl_get_*() function would have returned NULL. So, why does it return a = result which is so completely non-sense for the copy purpose? The same on Mac OS X 10.9.4 (type argument changed to ACL_TYPE_EXTENDED) = gives: "ACL not found." So even if it's a bug, it's at least a bug that = makes sense very much. >> Isn't there a better way? >=20 > Actually, there is. You try to obtain both POSIX and NFSv4 > ACLs for every file, even though the filesystem can always > support either one, or the other. >=20 > Take a look how eg. the cp(1) utility does it. The source > code is here: >=20 > = http://svnweb.freebsd.org/base/head/bin/cp/utils.c?revision=3D245960&view=3D= markup >=20 > Look for preserve_fd_acls() function. OK, I got this one. Anyway, I have two doubts left: 1. Is it correct that ACL_TYPE_DEFAULT is applicable for directories = only, or do regular files may have DEFAULT ACLs beside ACCESS or NFSv4? 2. What about hard links? Do all hard links of one inode share the same = ACL, or may each hard link have a different one? >> Is it really necessary to assemble the standard access rights into an = ACL, I did not expect this, Mac OS X doesn't do this, and in the present = situation it spoils up everything. >=20 > Well, yes, because the standard UNIX permissions are a part of ACL by = definition. OK, however, the extra assembly could easily be done in user space, and = also http://svnweb.freebsd.org/base/head/bin/cp/utils.c would benefit = from acl_*_np() functions that return only something if it is different = from the standard UNIX permissions, because any copy utility needs to = deal with the latter in any case. In the present situation we need to = deal with the standard UNIX perms more than twice. >> Anyway, for the present purpose it would be great to have at least a = function which simply informs whether a file system item got a = non-trivial ACL or not, without actually needing to load that ACL into = memory. >=20 > I don't think there would be any measurable speedup. You still > need to use a syscall to do this, and the syscall would need to > access ACL metadata. The only difference from what you're doing > right now is calling acl_is_trivial_np() and perhaps acl_free(), > which are both just a library functions, and thus cheap. I still think a simple ACL introspection syscall -- one which returns = status codes only, and not the whole lot -- would be very useful. Best regards Rolf From owner-posix1e@FreeBSD.ORG Mon Jul 14 08:59:00 2014 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5A842CD for ; Mon, 14 Jul 2014 08:58:59 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71C8F2F84 for ; Mon, 14 Jul 2014 08:58:59 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w62so3470154wes.29 for ; Mon, 14 Jul 2014 01:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=o0xgzKgLuisHaSYd1CV8JoIgZ6RkHg/Klg5eCAiQVYw=; b=iKsDs3D4SJj1bvONbBEof74T2pRohTAQ7epRF188wRXKFHyGpHZX0onFge8L8+5MVV FuH3rxWIVytxHmPmSTvtnQCv/jB9dxmbTmayv8HjcdhxlD/QyOGQDxfzAZYLyf0hOfXB oywL7tQytuD688Zrml6ye09Qs0UzeBJfbz1Y9ld9gH5azk7UhRQ09Sh9Wr+al51YzgxL 9LlxTLlLFp+iBS5Js33CK0uFCETR3mulvrMWWyYVY1zqqq9P4bD+gCZgbC9aeZqjnfWf XhJws2ArtdSeYZeQfonWEeJYV0zyuSexwHWdOg9rRfC3OqHaBqPwFa7OV/dIi79caWMy vsPg== X-Received: by 10.195.17.164 with SMTP id gf4mr17373577wjd.45.1405328337632; Mon, 14 Jul 2014 01:58:57 -0700 (PDT) Received: from brick.home (abpj92.neoplus.adsl.tpnet.pl. [83.8.51.92]) by mx.google.com with ESMTPSA id v14sm24095924wjw.38.2014.07.14.01.58.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Jul 2014 01:58:57 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 14 Jul 2014 10:58:54 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "Dr. Rolf Jansen" Subject: Re: Non-trivial ACLs only? Message-ID: <20140714085854.GC11111@brick.home> References: <6DF892D7-F4E2-4010-8AB9-5C798ED9C36B@obsigna.com> <20140713185509.GA8996@brick.home> <85785513-4D5F-4DCA-B1E4-2134C5AEAD22@obsigna.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <85785513-4D5F-4DCA-B1E4-2134C5AEAD22@obsigna.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: posix1e@FreeBSD.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 08:59:00 -0000 On 0713T2202, Dr. Rolf Jansen wrote: > Am 13.07.2014 um 15:55 schrieb Edward Tomasz NapieraÅ‚a : > > > On 0713T1215, Dr. Rolf Jansen wrote: > >> > >> ... > >> On Mac OS X, acl_get_link_np() returns real ACLs only, can I have this somehow for FreeBSD too? > > > > No, because it's a bug. Unfortunately I don't expect Apple to fix their implementation. > > If it's a bug, then for my purpose it's a very welcome one, because it keeps things easy on Mac OS X. So, I hope Apple keeps it as it is. Heh, yeah, well. It's a matter of personal preference, I guess :-) > > This one is wrong. There is no such thing as trivial default > > ACL. If you can actually retrieve ACL_TYPE_DEFAULT ACL and > > there are any entries in it, it's non-trivial. > > > > ... > > > >> This doesn't seem to work properly for directories, any ideas why? > > > > I think it's the problem above. > > OK, how then can I find out if there are ACLs set on directories or not. Please consider the following code snippet: Two of the three cases in your mail were correct. It's just that the one for ACL_TYPE_DEFAULT was wrong. > #include > #include > #include > #include > > int main(int argc, char *const argv[]) > { > mkdir("test_acl_dir", 0755); > > if (acl_get_link_np("test_acl_dir", ACL_TYPE_DEFAULT)) > printf("ACL found.\n"); > else > printf("ACL not found.\n"); > > return 0; > } > > clang acltest.c -o acltest > rm -rf test_acl_dir && ./acltest > > On FreeBSD 9.2, the above command sequence results in "ACL found." Actually no ACL has been set, and I would have expected, that any acl_get_*() function would have returned NULL. So, why does it return a result which is so completely non-sense for the copy purpose? Because NULL return means error, and in this case there is no error - it's just that there is no default ACL set. In FreeBSD, this is expressed by empty (zero entries) ACL. > The same on Mac OS X 10.9.4 (type argument changed to ACL_TYPE_EXTENDED) gives: "ACL not found." So even if it's a bug, it's at least a bug that makes sense very much. > > >> Isn't there a better way? > > > > Actually, there is. You try to obtain both POSIX and NFSv4 > > ACLs for every file, even though the filesystem can always > > support either one, or the other. > > > > Take a look how eg. the cp(1) utility does it. The source > > code is here: > > > > http://svnweb.freebsd.org/base/head/bin/cp/utils.c?revision=245960&view=markup > > > > Look for preserve_fd_acls() function. > > OK, I got this one. > > Anyway, I have two doubts left: > 1. Is it correct that ACL_TYPE_DEFAULT is applicable for directories only, or do regular files may have DEFAULT ACLs beside ACCESS or NFSv4? The default ACL may only be set on directories. It may never be used with NFSv4 ACLs, ie. can only be used with POSIX (ACL_TYPE_ACCESS) ACLs. > 2. What about hard links? Do all hard links of one inode share the same ACL, or may each hard link have a different one? Yes, all hard links share the same ACL. > >> Is it really necessary to assemble the standard access rights into an ACL, I did not expect this, Mac OS X doesn't do this, and in the present situation it spoils up everything. > > > > Well, yes, because the standard UNIX permissions are a part of ACL by definition. > > OK, however, the extra assembly could easily be done in user space, and also http://svnweb.freebsd.org/base/head/bin/cp/utils.c would benefit from acl_*_np() functions that return only something if it is different from the standard UNIX permissions, because any copy utility needs to deal with the latter in any case. In the present situation we need to deal with the standard UNIX perms more than twice. > > >> Anyway, for the present purpose it would be great to have at least a function which simply informs whether a file system item got a non-trivial ACL or not, without actually needing to load that ACL into memory. > > > > I don't think there would be any measurable speedup. You still > > need to use a syscall to do this, and the syscall would need to > > access ACL metadata. The only difference from what you're doing > > right now is calling acl_is_trivial_np() and perhaps acl_free(), > > which are both just a library functions, and thus cheap. > > I still think a simple ACL introspection syscall -- one which returns status codes only, and not the whole lot -- would be very useful. Still, it would be only marginally faster (if at all) than a routine that retrieves the ACL and then check whether it's trivial. From owner-posix1e@FreeBSD.ORG Mon Jul 14 19:14:54 2014 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C5DDDE8; Mon, 14 Jul 2014 19:14:54 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F019A2913; Mon, 14 Jul 2014 19:14:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1405365289; l=2605; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=/QBr39jDELKwIEIneoEO56kNS78=; b=y21ygadU/VaOEkvxz03Li79FI9DausF14d6Zb248UMf++E0eJzYAr4xsSrg421aeAMy rnmRPRZUooy4dpXLi8t1+iXlmwvxAb17u5EPBafMejqa3PwkO7K6rwbNh3F5LVuDbYlCz F3+Q7nZK06WKx3X7dK9OJSjNIrxjQ3LdH1o= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU1DqWLqtDlVqo50LuK X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (c94a6333.virtua.com.br [201.74.99.51]) by smtp.strato.de (RZmta 35.2 DYNA|AUTH) with ESMTPSA id z01931q6EJEndgL (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Mon, 14 Jul 2014 21:14:49 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id DA5CFFA47919; Mon, 14 Jul 2014 16:14:40 -0300 (BRT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Non-trivial ACLs only? From: "Dr. Rolf Jansen" In-Reply-To: <20140714085854.GC11111@brick.home> Date: Mon, 14 Jul 2014 16:14:39 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6DF892D7-F4E2-4010-8AB9-5C798ED9C36B@obsigna.com> <20140713185509.GA8996@brick.home> <85785513-4D5F-4DCA-B1E4-2134C5AEAD22@obsigna.com> <20140714085854.GC11111@brick.home> To: posix1e@FreeBSD.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 19:14:54 -0000 Am 14.07.2014 um 05:58 schrieb Edward Tomasz Napiera=C5=82a = : Many thanks for your response, I very much appreciate your help. I = think, I am almost there. >> OK, how then can I find out if there are ACLs set on directories or = not. Please consider the following code snippet: >=20 > Two of the three cases in your mail were correct. It's just > that the one for ACL_TYPE_DEFAULT was wrong. >=20 >> #include >> #include >> #include >> #include >>=20 >> int main(int argc, char *const argv[]) >> { >> mkdir("test_acl_dir", 0755); >>=20 >> if (acl_get_link_np("test_acl_dir", ACL_TYPE_DEFAULT)) >> printf("ACL found.\n"); >> else >> printf("ACL not found.\n"); >>=20 >> return 0; >> } >>=20 >> clang acltest.c -o acltest >> rm -rf test_acl_dir && ./acltest >>=20 >> On FreeBSD 9.2, the above command sequence results in "ACL found." = Actually no ACL has been set, and I would have expected, that any = acl_get_*() function would have returned NULL. So, why does it return a = result which is so completely non-sense for the copy purpose? >=20 > Because NULL return means error, and in this case there is no > error - it's just that there is no default ACL set. In FreeBSD, > this is expressed by empty (zero entries) ACL. Please consider the following variant of the above example: #include #include #include #include struct acl_t_head { unsigned int acl_maxcnt; unsigned int acl_cnt; }; typedef struct acl_t_head *acl_head_t; int main(int argc, char *const argv[]) { mkdir("test_acl_dir", 0755); acl_head_t acl =3D acl_get_link_np("test_acl_dir", ACL_TYPE_ACCESS); if (acl->acl_cnt) printf("ACL found: %d of %d entries.\n", acl->acl_cnt, = acl->acl_maxcnt); else printf("ACL not found: %d of %d entries.\n", acl->acl_cnt, = acl->acl_maxcnt); return 0; } clang acltest.c -o acltest rm -rf test_acl_dir && ./acltest The above command sequence results in: ACL found: 3 of 254 entries. Anyway, I actually start wondering whether my file system cloning tool = needs to address the ACLs via the respective API at all. It doesn't want = to process any ACL, but if present, only transfer it from the original = to the cloned file system item. I will have a closer look now on the = posix1e.acl_access, posix1e.acl_default, and nfs4.acl extended = attributes. Perhaps it is as simple, to straightly copy over everything = what is in the extattr system name space. Best regards Rolf= From owner-posix1e@FreeBSD.ORG Tue Jul 15 02:37:22 2014 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A021F9AD; Tue, 15 Jul 2014 02:37:22 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07ADC2D77; Tue, 15 Jul 2014 02:37:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1405391836; l=1014; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=1DMRnBVLaeRFPUSro6TBkbHV5AU=; b=KkU+zIH+5ufwI+uIOWTvX6gfDJcbEy/QJeU0yQUEnZWA3tVO1cySRBNnf4S2SUhVWaQ OhGQOHKuqSPkd2w99lRbMpt88x9XI7ALKdGI2JLyID74+V10eKyjiw8msIp7c+Y0/7Lp8 v1WVb0lu3KQm2u/IjYUJ2BRSoJGzyhy79wM= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU1DqWLqtDlVqo50LuK X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (c94a6333.virtua.com.br [201.74.99.51]) by smtp.strato.de (RZmta 35.2 DYNA|AUTH) with ESMTPSA id R01b98q6F2bGeSF (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Tue, 15 Jul 2014 04:37:16 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id A8561FA47919; Mon, 14 Jul 2014 23:37:13 -0300 (BRT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Non-trivial ACLs only? From: "Dr. Rolf Jansen" In-Reply-To: Date: Mon, 14 Jul 2014 23:37:12 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6DF892D7-F4E2-4010-8AB9-5C798ED9C36B@obsigna.com> <20140713185509.GA8996@brick.home> <85785513-4D5F-4DCA-B1E4-2134C5AEAD22@obsigna.com> <20140714085854.GC11111@brick.home> To: posix1e@FreeBSD.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 02:37:22 -0000 Am 14.07.2014 um 16:14 schrieb Dr. Rolf Jansen : > Am 14.07.2014 um 05:58 schrieb Edward Tomasz Napiera=C5=82a = : >=20 >> Because NULL return means error, and in this case there is no >> error - it's just that there is no default ACL set. In FreeBSD, >> this is expressed by empty (zero entries) ACL. >=20 > Please consider the following variant of the above example: > ... > acl_head_t acl =3D acl_get_link_np("test_acl_dir", ACL_TYPE_ACCESS); > ... >=20 > clang acltest.c -o acltest > rm -rf test_acl_dir && ./acltest >=20 > The above command sequence results in: > ACL found: 3 of 254 entries. I am sorry, I tested against the wrong ACL type (my stupid copy and = paste error). I repeated the test using ACL_TYPE_DEFAULT, and as a = matter of fact it resulted in: ACL not found: 0 of 254 entries. Up to this end, everything is clear to me now. Please excuse me = bothering you with a wrong test example. Many thanks and best regards Rolf From owner-posix1e@FreeBSD.ORG Tue Jul 15 05:09:25 2014 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2E2B31F for ; Tue, 15 Jul 2014 05:09:25 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6858829C9 for ; Tue, 15 Jul 2014 05:09:25 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q58so1547999wes.7 for ; Mon, 14 Jul 2014 22:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=aXrBw7JQv6zxl7X+65nVthr0im4dRs053sh0BMB0RgQ=; b=iaRYdB61/ZhI0392wKasE0U1kA0+YramvAlISZq53E0XcOA8L89w51wmvvOtXX666s uWMiejnQsaiwg68U9DCdigJ5pu6oysMfIDqIV1qCoCfc7E1jZ3ucPAyztnKqeI07F9lP gJlhx4DdJMqmv313V4jS8A7Ps9zyAjQi4OyKy2KS49ui5cJs3ImbHpbu2lU/iCbdFqqG mQ2wdoaVFXiM1sjbQPmY4q/Qksba9K/ZEdIHnIjHo6hZY3ImgWx50GbLbGHtw68hO29S e8Nkj2uoXeJtVaaz7b0Ds/5QTL0Aoxi/VOzDcH/ckRnMwGY9+1rU6RulQyGS3sd1OUMO wXFA== X-Received: by 10.194.192.201 with SMTP id hi9mr24718172wjc.28.1405400963733; Mon, 14 Jul 2014 22:09:23 -0700 (PDT) Received: from brick.home (adhm239.neoplus.adsl.tpnet.pl. [79.184.168.239]) by mx.google.com with ESMTPSA id i4sm39199727wib.21.2014.07.14.22.09.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Jul 2014 22:09:23 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 15 Jul 2014 07:09:22 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "Dr. Rolf Jansen" Subject: Re: Non-trivial ACLs only? Message-ID: <20140715050922.GB2338@brick.home> References: <6DF892D7-F4E2-4010-8AB9-5C798ED9C36B@obsigna.com> <20140713185509.GA8996@brick.home> <85785513-4D5F-4DCA-B1E4-2134C5AEAD22@obsigna.com> <20140714085854.GC11111@brick.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: posix1e@FreeBSD.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 05:09:26 -0000 On 0714T1614, Dr. Rolf Jansen wrote: > Am 14.07.2014 um 05:58 schrieb Edward Tomasz NapieraÅ‚a : > > Many thanks for your response, I very much appreciate your help. I think, I am almost there. > > >> OK, how then can I find out if there are ACLs set on directories or not. Please consider the following code snippet: > > > > Two of the three cases in your mail were correct. It's just > > that the one for ACL_TYPE_DEFAULT was wrong. > > > >> #include > >> #include > >> #include > >> #include > >> > >> int main(int argc, char *const argv[]) > >> { > >> mkdir("test_acl_dir", 0755); > >> > >> if (acl_get_link_np("test_acl_dir", ACL_TYPE_DEFAULT)) > >> printf("ACL found.\n"); > >> else > >> printf("ACL not found.\n"); > >> > >> return 0; > >> } > >> > >> clang acltest.c -o acltest > >> rm -rf test_acl_dir && ./acltest > >> > >> On FreeBSD 9.2, the above command sequence results in "ACL found." Actually no ACL has been set, and I would have expected, that any acl_get_*() function would have returned NULL. So, why does it return a result which is so completely non-sense for the copy purpose? > > > > Because NULL return means error, and in this case there is no > > error - it's just that there is no default ACL set. In FreeBSD, > > this is expressed by empty (zero entries) ACL. > > Please consider the following variant of the above example: > > #include > #include > #include > #include > > struct acl_t_head > { > unsigned int acl_maxcnt; > unsigned int acl_cnt; > }; > typedef struct acl_t_head *acl_head_t; > > int main(int argc, char *const argv[]) > { > mkdir("test_acl_dir", 0755); > > acl_head_t acl = acl_get_link_np("test_acl_dir", ACL_TYPE_ACCESS); > if (acl->acl_cnt) > printf("ACL found: %d of %d entries.\n", acl->acl_cnt, acl->acl_maxcnt); > else > printf("ACL not found: %d of %d entries.\n", acl->acl_cnt, acl->acl_maxcnt); > > return 0; > } > > clang acltest.c -o acltest > rm -rf test_acl_dir && ./acltest > > The above command sequence results in: > ACL found: 3 of 254 entries. Yup. You asked for ACL_TYPE_ACCESS (not ACL_TYPE_DEFAULT), and you probably got a trivial ACL synthesized from UNIX permissions. > Anyway, I actually start wondering whether my file system cloning tool needs to address the ACLs via the respective API at all. It doesn't want to process any ACL, but if present, only transfer it from the original to the cloned file system item. I will have a closer look now on the posix1e.acl_access, posix1e.acl_default, and nfs4.acl extended attributes. Perhaps it is as simple, to straightly copy over everything what is in the extattr system name space. Not a good idea - those are UFS-specific; this won't work with ZFS or NFSv4. From owner-posix1e@FreeBSD.ORG Tue Jul 15 05:10:16 2014 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3889E343 for ; Tue, 15 Jul 2014 05:10:16 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0B1829D6 for ; Tue, 15 Jul 2014 05:10:15 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id a1so4279003wgh.23 for ; Mon, 14 Jul 2014 22:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=Fuk7kBpZrT7nmp6nTu396F8HWgZ60BMNf9yDIsiR524=; b=LEEvrBj1xMPfxZbSfTaCGF71nn3P3paPDLy443kL0gkvAdsFiBDJATFqYyBTrF/eCU sU/ahq2zNUc1eZf7Hzkd8OqILnQnsJlmSwWFq8HPhrNoEpgWnPMotr4Fw1dlp33v4QSF IxVbXTkySkUgIaooDHxzrhPWZF30swMFdNG0xFxvXPBwKzZRhnxlsAXD2v/BGXrsc7nv eNjqsZjjqA2A0a34856LAVmiOGPxlIIzqTZi/nCRWU2RddKpMCUBEUaxoqiK5OCkDcbo nTRpnA6GZ9G4F4nhPyo9RkQIqaic5+Q585F6SSePcC1XrjL6+ucnOYoyOHQYbpmlnJK6 FBTg== X-Received: by 10.194.92.177 with SMTP id cn17mr24674615wjb.71.1405401014112; Mon, 14 Jul 2014 22:10:14 -0700 (PDT) Received: from brick.home (adhm239.neoplus.adsl.tpnet.pl. [79.184.168.239]) by mx.google.com with ESMTPSA id w6sm30046999wjr.4.2014.07.14.22.10.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Jul 2014 22:10:13 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 15 Jul 2014 07:10:12 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "Dr. Rolf Jansen" Subject: Re: Non-trivial ACLs only? Message-ID: <20140715051012.GC2338@brick.home> References: <6DF892D7-F4E2-4010-8AB9-5C798ED9C36B@obsigna.com> <20140713185509.GA8996@brick.home> <85785513-4D5F-4DCA-B1E4-2134C5AEAD22@obsigna.com> <20140714085854.GC11111@brick.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: posix1e@FreeBSD.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 05:10:16 -0000 On 0714T2337, Dr. Rolf Jansen wrote: > Am 14.07.2014 um 16:14 schrieb Dr. Rolf Jansen : > > > Am 14.07.2014 um 05:58 schrieb Edward Tomasz NapieraÅ‚a : > > > >> Because NULL return means error, and in this case there is no > >> error - it's just that there is no default ACL set. In FreeBSD, > >> this is expressed by empty (zero entries) ACL. > > > > Please consider the following variant of the above example: > > ... > > acl_head_t acl = acl_get_link_np("test_acl_dir", ACL_TYPE_ACCESS); > > ... > > > > clang acltest.c -o acltest > > rm -rf test_acl_dir && ./acltest > > > > The above command sequence results in: > > ACL found: 3 of 254 entries. > > I am sorry, I tested against the wrong ACL type (my stupid copy and paste error). I repeated the test using ACL_TYPE_DEFAULT, and as a matter of fact it resulted in: > ACL not found: 0 of 254 entries. > > Up to this end, everything is clear to me now. Please excuse me bothering you with a wrong test example. No problem, you're welcome. Don't hesitate to ask if you have any more questions. From owner-posix1e@FreeBSD.ORG Tue Jul 15 21:31:16 2014 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2602AAEA for ; Tue, 15 Jul 2014 21:31:16 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A63D72710 for ; Tue, 15 Jul 2014 21:31:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1405459871; l=1909; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=tV+PMwH+AD77GJ0SaKdfvNbPEGw=; b=dLqK1zes2u9cI7CiakoDChMpqnXQKDx109p2ndaYWuLwGsLA5AAS1hDCZogYonj61Xt Kd+DT3BKRqfR15idII3lXvU9defBnPaMrz1jROgiEDovNaI0zqDVNGUlSnfdAOTW/oOHt 5jPQffP5EIeY2QhVEq8ZWKykF3OE92VBXDU= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU1DqWLqtDlVqo50LuK X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (c94a6333.virtua.com.br [201.74.99.51]) by smtp.strato.de (RZmta 35.2 DYNA|AUTH) with ESMTPSA id K04b49q6FLVBnpK (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) for ; Tue, 15 Jul 2014 23:31:11 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 89EE7FA47919 for ; Tue, 15 Jul 2014 18:31:08 -0300 (BRT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Non-trivial ACLs only? From: "Dr. Rolf Jansen" In-Reply-To: <20140715050922.GB2338@brick.home> Date: Tue, 15 Jul 2014 18:31:06 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <79BB29F6-5610-4AC3-9D0E-C84A72DA619F@obsigna.com> References: <6DF892D7-F4E2-4010-8AB9-5C798ED9C36B@obsigna.com> <20140713185509.GA8996@brick.home> <85785513-4D5F-4DCA-B1E4-2134C5AEAD22@obsigna.com> <20140714085854.GC11111@brick.home> <20140715050922.GB2338@brick.home> To: posix1e@FreeBSD.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 21:31:16 -0000 Am 15.07.2014 um 02:09 schrieb Edward Tomasz Napiera=C5=82a = : > On 0714T1614, Dr. Rolf Jansen wrote: >> Anyway, I actually start wondering whether my file system cloning = tool needs to address the ACLs via the respective API at all. It doesn't = want to process any ACL, but if present, only transfer it from the = original to the cloned file system item. I will have a closer look now = on the posix1e.acl_access, posix1e.acl_default, and nfs4.acl extended = attributes. Perhaps it is as simple, to straightly copy over everything = what is in the extattr system name space. >=20 > Not a good idea - those are UFS-specific; this won't work with ZFS or = NFSv4. OK, I now check the file systems before skipping ACL reading, see the = code snippet below. I got another question though. Is it correct to assume that in the case = of non-trivial Access/NFSv4 ACLs the acl_cnt is always greater than 3? = This comes to my mind, because the standard UNIX access rights would = always occupy 3 ACL entries, and any additional stuff would increase the = count, right? Best regards Rolf // Reading the ACLs if (*gSourceFSType =3D=3D *(int *)"ufs" && *gDestinFSType =3D=3D *(int = *)"ufs") // In the case of UFS2 file systems, the ACLs have been read already // as part of the extended attributes within the system namespace, // and therefore it is not necessary to read them again. xmd->acl[0] =3D xmd->acl[1] =3D NULL; else { acl_t acl; int trivial; if ((acl =3D acl_get_link_np(src, ACL_TYPE_ACCESS)) && (acl_is_trivial_np(acl, &trivial) || trivial)) { acl_free(acl); acl =3D NULL; } xmd->acl[0] =3D acl; if (!S_ISDIR(st->st_mode)) xmd->acl[1] =3D NULL; else { if ((acl =3D acl_get_link_np(src, ACL_TYPE_DEFAULT)) && ((uint*)acl)[1] =3D=3D 0) { acl_free(acl); acl =3D NULL; } xmd->acl[1] =3D acl; } } From owner-posix1e@FreeBSD.ORG Wed Jul 16 13:58:18 2014 Return-Path: Delivered-To: posix1e@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0034545 for ; Wed, 16 Jul 2014 13:58:18 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F83C2B97 for ; Wed, 16 Jul 2014 13:58:18 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id n3so1392769wiv.1 for ; Wed, 16 Jul 2014 06:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=MgcrQsuu5j5Bp4qG2L1p7Y3rv4+VgVtAZpeBuLuOnno=; b=CsetIp1pJc0S/CILFEnhrgMTDq+gViIr7viEk/kt8sivz02POgARuVC8RPauZjjmCi 8GREEQx4r+YqXS1d/HtFeRnrwAeZwW8W1LWfpvWrfYeyU6P1oZcJgvcJBuYZjWTE30OL SMiYWkjdXP7dgDzfsFXewGB0H8tE1ML4ajD8wRdBy+FHCGPZ7lT8AW8f2T5eyZyJ0R0P qQcKD2xza7ikEEEINT56bwbNeSYbr0GKpigOlSkhSYjIS430mkVeckEdohcJweXUerbk HT8kOjGJ5eRQ26T1tart2dmgVDguGh7RDray/l6Nv91t2kvZSZ4T8OvMQBwb1Us0QPXF auzA== X-Received: by 10.180.36.225 with SMTP id t1mr14254390wij.38.1405519094493; Wed, 16 Jul 2014 06:58:14 -0700 (PDT) Received: from brick.home (ahz24.neoplus.adsl.tpnet.pl. [83.25.207.24]) by mx.google.com with ESMTPSA id x3sm9351908wia.11.2014.07.16.06.58.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Jul 2014 06:58:13 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Wed, 16 Jul 2014 15:58:05 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "Dr. Rolf Jansen" Subject: Re: Non-trivial ACLs only? Message-ID: <20140716135805.GC5500@brick.home> References: <6DF892D7-F4E2-4010-8AB9-5C798ED9C36B@obsigna.com> <20140713185509.GA8996@brick.home> <85785513-4D5F-4DCA-B1E4-2134C5AEAD22@obsigna.com> <20140714085854.GC11111@brick.home> <20140715050922.GB2338@brick.home> <79BB29F6-5610-4AC3-9D0E-C84A72DA619F@obsigna.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <79BB29F6-5610-4AC3-9D0E-C84A72DA619F@obsigna.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: posix1e@FreeBSD.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 13:58:18 -0000 On 0715T1831, Dr. Rolf Jansen wrote: > Am 15.07.2014 um 02:09 schrieb Edward Tomasz NapieraÅ‚a : > > On 0714T1614, Dr. Rolf Jansen wrote: > >> Anyway, I actually start wondering whether my file system cloning tool needs to address the ACLs via the respective API at all. It doesn't want to process any ACL, but if present, only transfer it from the original to the cloned file system item. I will have a closer look now on the posix1e.acl_access, posix1e.acl_default, and nfs4.acl extended attributes. Perhaps it is as simple, to straightly copy over everything what is in the extattr system name space. > > > > Not a good idea - those are UFS-specific; this won't work with ZFS or NFSv4. > > OK, I now check the file systems before skipping ACL reading, see the code snippet below. Seems ok. > I got another question though. Is it correct to assume that in the case of non-trivial Access/NFSv4 ACLs the acl_cnt is always greater than 3? This comes to my mind, because the standard UNIX access rights would always occupy 3 ACL entries, and any additional stuff would increase the count, right? Not with NFSv4 ACLs. There you might have less than three entries. You start with three (usually), but you can remove any of those, and the result will be non-trivial. From owner-posix1e@FreeBSD.ORG Thu Jul 17 00:49:31 2014 Return-Path: Delivered-To: posix1e@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBA864C7; Thu, 17 Jul 2014 00:49:30 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39B3626BE; Thu, 17 Jul 2014 00:49:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1405558165; l=1937; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=BUBUMTYHC6CS9kQ+RVPs1RYLLFI=; b=EqqOPSFCVEJAGpN48jFXWHq/GnzS4iHEeuQ4XPb71DAe0g+OINCMAJTUC+uD16a+4eE 0VydIPTVDvA8VdVBLIQyqsHOsDlRkLyqbxKKjptA3fSUnA6hRt1foEWTiECJdZSwWOxmU qsRpa0xGPh8V4XNm64AHM2W+PkgggGW7kUY= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU1DqWLqtDlVqo50LuK X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (c94a6333.virtua.com.br [201.74.99.51]) by smtp.strato.de (RZmta 35.2 DYNA|AUTH) with ESMTPSA id Z02895q6H0nPzIV (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Thu, 17 Jul 2014 02:49:25 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id DB8D8FA47923; Wed, 16 Jul 2014 21:49:21 -0300 (BRT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Non-trivial ACLs only? From: "Dr. Rolf Jansen" In-Reply-To: <20140716135805.GC5500@brick.home> Date: Wed, 16 Jul 2014 21:49:19 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6BB3EB3C-74EA-4CF2-B2EF-4EADC03F816C@obsigna.com> References: <6DF892D7-F4E2-4010-8AB9-5C798ED9C36B@obsigna.com> <20140713185509.GA8996@brick.home> <85785513-4D5F-4DCA-B1E4-2134C5AEAD22@obsigna.com> <20140714085854.GC11111@brick.home> <20140715050922.GB2338@brick.home> <79BB29F6-5610-4AC3-9D0E-C84A72DA619F@obsigna.com> <20140716135805.GC5500@brick.home> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: Apple Mail (2.1878.6) Cc: posix1e@FreeBSD.org X-BeenThere: posix1e@FreeBSD.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "POSIX.1e Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 00:49:31 -0000 Am 16.07.2014 um 10:58 schrieb Edward Tomasz Napiera=C5=82a = : > On 0715T1831, Dr. Rolf Jansen wrote: >> Am 15.07.2014 um 02:09 schrieb Edward Tomasz Napiera=C5=82a = : >>> On 0714T1614, Dr. Rolf Jansen wrote: >>>> Anyway, I actually start wondering whether my file system cloning = tool needs to address the ACLs via the respective API at all. It doesn't = want to process any ACL, but if present, only transfer it from the = original to the cloned file system item. I will have a closer look now = on the posix1e.acl_access, posix1e.acl_default, and nfs4.acl extended = attributes. Perhaps it is as simple, to straightly copy over everything = what is in the extattr system name space. >>>=20 >>> Not a good idea - those are UFS-specific; this won't work with ZFS = or NFSv4. >>=20 >> OK, I now check the file systems before skipping ACL reading, see the = code snippet below. >=20 > Seems ok. >=20 >> I got another question though. Is it correct to assume that in the = case of non-trivial Access/NFSv4 ACLs the acl_cnt is always greater than = 3? This comes to my mind, because the standard UNIX access rights would = always occupy 3 ACL entries, and any additional stuff would increase the = count, right? >=20 > Not with NFSv4 ACLs. There you might have less than three entries. > You start with three (usually), but you can remove any of those, > and the result will be non-trivial. Edward, Many thanks for your great help. I finished my optimization efforts = successfully. My cloning tool now consumes much less system resources = during file tree cloning and in addition cloning is now about 30 % = faster. I submitted the changes to the repository at Google Code = (https://code.google.com/p/clone/source/list), and I will also submit an = update to the FreeBSD ports (http://www.freshports.org/sysutils/clone/) = soon. Best regards Rolf