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."