From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 03:33:18 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 651A316A4CE for ; Mon, 9 Feb 2004 03:33:18 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 875BC43D1D for ; Mon, 9 Feb 2004 03:33:17 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])i19BSFG02801; Mon, 9 Feb 2004 12:28:15 +0100 (MET) Date: Mon, 9 Feb 2004 12:28:15 +0100 (CET) From: Harti Brandt To: Tim Kientzle In-Reply-To: <40269DF5.2090806@acm.org> Message-ID: <20040209122341.S32427@beagle.fokus.fraunhofer.de> References: <4025A0DD.2010607@acm.org> <20040208134125.L28775@beagle.fokus.fraunhofer.de> <40269DF5.2090806@acm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Odd ACL question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2004 11:33:18 -0000 On Sun, 8 Feb 2004, Tim Kientzle wrote: TK>On Sat, 7 Feb 2004, Tim Kientzle wrote: TK>>Joerg Schilling's "star" archives ACLs as follows: TK>> TK>>"user::rwx,group::r--,group:mail:rw-:6,mask::rw-,other::r--" TK>> TK>>Note the "group:mail:rw-:6" entry that contains a fourth TK>>field with the uid/gid number. ... TK>> TK>>Question: Is this a useful extension? TK> TK>Harti Brandt responded: TK>> It definitely is. Joerg and I had several hours of talk on this issue. TK>> If you, for example, restore on a system that usually gets its passwd from TK>> YP or LDAP and you don't have it available ... TK> TK>Ah. That's the example I needed. Now to figure out how to implement TK>such functionality; hacking the acl library functions may TK>not be the best approach, but I'm equally dismayed by the prospect TK>of duplicating the acl library functions in my code. ;-( TK> TK>> As far as I know there are options to star that let you select the exact TK>> behaviour in these cases. TK> TK>This is one difference between 'star' and my work: 'star' offers TK>a great deal of control over the archiving/dearchiving TK>process; my work tries to remove the need for such control TK>by using intelligent algorithms. For example, bsdtar/libarchive TK>doesn't require you to specify the compression when reading archives; TK>it determines it automatically. TK> TK>In this case, I'm considering: TK> * If the username exists, use that. TK> * If the username does not exist and the UID is not already in TK> use, issue a warning and use the UID. TK> * If the username exists and the UID conflicts with the local TK> system, ??? TK> TK>This last case is the tough one. My temptation: map it to TK>an unused UID, issue a warning about the remap, and keep going. That may cause the problem I described. This may leave a file in a user directory that the user cannot delete without intervention of the root user, but its probably the simplest solution. What about non-existing groups? I remember talking with Joerg about this, but cannot remember the outcome of this. You may want to ask him. TK>There are certainly rare cases where manual control is TK>needed. That's why I'm pleased that 'star' is available TK>in ports. ;-) Are you going to replace that horrible thing called GNU tar in the bases system? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org